Re: [tracecompass-dev] Data Provider Descriptor

[tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>]

Hi Bernd,

Thanks for starting the discussion on this topic.

On 5/4/20 2:03 PM, tracecompass developer discussions wrote:
> Hi,
>
> I'm currently looking into the function duration statistics data provider. I'm investigating how we could define a statistics data provider generically. Also, I followed  discussions on IRC on the data provider descriptor that describes a data provider. I'm looking at this topic with also the client-server architecture and TSP (Trace Server Protocol) in mind. I'm happy to see interests from different people in this topic. 
>
> First of all, the data provider descriptor (IDataProviderDescriptor), is meant to describe the data provider.  It's meant to give enough information to client users of the data provider to know what they can do with thee data.  It supposed describe what the type the data provider is (XY Chart, Time Graph, Virtual table etc.) and what type of data it provides (tree, XY, states, combinations etc.). It gives a short description and name that can be displayed to users. The current implementation is limited, and only returns the data provider type, description and name. In the implementation, this data is quite static and no data provider instance have to be created.

I think a data provider descriptor should be as static as possible, ie
independent of the trace. Or at least, there should be a static version
of descriptor that gives the client basic information as to what data
could be provided, even if no trace is available and give a hint as to
how this data should be shown, what columns should be displayed and
their specific format. This way, if the view is opened and is empty, or
even if there's no trace, the columns can still be initialized, etc

At the next level, when a specific trace is opened and an actual data
provider is instanciated, then there _may_ be additional data, like an
extra statistics column for a trace that contains specific data, or a
column for the trace in case of experiments, in which case, it will be
returned with the tree's data and implementations are then free to do
what they wish with it, ignore it or display it.

Also, formatting of data should be a client-side feature imho, as
different data/time format can be selected by users. A good exercice for
the descriptors/data provider API would be to have absolutely no
specific view classes in Trace Compass!!

And - I'm opening a door here - maybe the descriptors could also include
potential action types on the corresponding data? We haven't really
looked into how actions should be defined by server or client, but the
descriptors could give hints as to what the user may want to do with the
data, etc...

As a side note, another data provider that will need to be implemented
is the density data provider (histograms)

> Secondly, the function statistics duration data provider, is a tree data provider and doesn't have any XY or time chart associated with. The current implementation provides a list of entries with ID, parent ID and label. This data is dynamic and an instance of the data provider is needed to get it. The support of columns in the tree data provider are defined in the API only, but the Trace Compass UI is not using it at the moment. Special domain specific APIs are provided for that. 
>
> The earlier mentioned API for the columns exists in TmfTreeModel (headers) and labels per column in the TmfTreeDataModel. However, most implementations inheriting from the TmfTreeDataModel (and TmfTreeModel respectively) have not been updated for that. The headers API only has the label, but no description of the data type that the data in column contains. The TmfTreeModel is returned by method ITmfTreeDataProvider#fetchTree() of the tree data provider, and it contains a list of TmfTreeDataModel (one per row).
>
> In my investigation, I'm looking into describing the columns using a column descriptor that will be return instead of the list of header strings. It will give more details on the columns, e.g. what data type it provides, (e.g. string, time, duration, numeric). The description of the columns could be static (I think), but right now a data provider instance needs to be created and fetchTree() call is needed. Not sure how easy it will be to have it part of the IDataProviderDescriptor.
I think it can definitely be part of the descriptor as a list of column
name, description, format, [default sort]. Descriptors are provided by
factories, which are managed through extension points, so it should be
easy-ish to do.
> The description of the column is similar what patch (https://git.eclipse.org/r/#/c/161887/) wants to add to the data provider descriptor (IDataProviderDescriptor). This addition would be specific to XY charts and for a single type series.

What this patch introduces among other things is the DataType
enumeration. In the patch, the data type is associated with a formatter,
but it doesn't have to be, it can just be a descriptive data type and
the corresponding formatter can be client-side.

Best regards,

Geneviève