Make models and model parsers plugins too

[KOLANICH]

I may wanna try to integrate ksy-generated model parsers in XGBoost. It would be nice to have model parsers somehow standoff from models evaluation. But xgboost already supports several kinds of models. It would be nice to modularize everything enough to allow to choose model parser implementation separately from a model and to allow adding custom models.

[trivialfis]

@KOLANICH Hi, can you elaborate a little about what is "ksy", I couldn't find any reference on Google.

What kind of model are you talking about? My first impression around the word "model" is tree/linear. I'm implementing a Json port of model IO, see #3916 , does that help?

[KOLANICH]

Hi, can you elaborate a little about what is "ksy"

TLDR: machine-readable binary format specification compiled into parsing code in variety of languages. See #3170 and especially the links for more info.

[KOLANICH]

What kind of model are you talking about? My first impression around the word "model" is tree/linear.

Yes, I mean them. I mean I'd like serialization/deserialization be separated from learning stuff in the way allowing to swap serialization/deserialization engines in run-time rather than in compile-time.

[hcho3]

Closing for now. After the JSON input format is adopted, we will add plug-ins to accept various binary encodings of JSON.

[KOLANICH]

we will add plug-ins to accept various binary encodings of JSON.

I don't mean binary encodings of JSON, I mean a binary format. IMHO parsing JSON repr in order to generate a binary format is overkill. I mean that JSON and its binary encodings are essentially key-value pairs. So your interface to JSON-like serializers should probably look like as passing already constructed JSON representation back and forth. But for a binary format it is unsuitable, for a binary format we need not JSON internal representation, but something more close to XGBoost internal representation.

[hcho3]

something more close to XGBoost internal representation.

I’m not sure if we want to establish plugin system that allows access to internals. If anything, the trend is greater encapsulation. See #3972. You are of course free to make your fork of XGBoost and modify it at will, but I’m afraid we cannot have a plugin system touching internals in the main repository.

cc @RAMitchell

[KOLANICH]

something more close to XGBoost internal representation.

is not necessarily internal representation. It is something, not requiring me to do perversions like parsing json-like repr.

For example a framework of methods. Core defines an abstract class with virtual methods. Plugin inherits the class. Plugin passes the object of the class back to core. Core does serialization by calling its methods, passing the data to be serialized into the methods. The methods are called for each entity, like an ensemble, regression model, tree model, non-leaf node, leaf node. It would be nice to have an exporter plugin passing itself into python, so it can be possible to write an exporter in python.

[hcho3]

passing the data to be serialized into the methods

This sounds like accessing internal representation to me?

Reopening to continue discussion

[hcho3]

We may pursue this idea in some future time, but for the time being, there are other priorities.

[trivialfis]

I don't think this will be part of xgboost.