Hi Trace Compass devs,
I have been looking at updating our IDataProviderFactorys to work with Trace Server.
While doing so I saw that many of the standard Trace Compass data provider factories return a TmfTreeXYCompositeDataProvider to handle multiple traces together. At the moment we simply don't support experiments/multiple-traces for our own data providers.
Returning a TmfTreeXYCompositeDataProvider gets us that multi-trace support very easily, but the TmfTreeXYCompositeDataProvider is not API itself. Is there an API compliant way to use this code?
[Bernd]
No, there is no compliant way to do it. We kept this class internal until we were sure that it is used outside Trace Compass upstream code. We can make it API along with sibling classes (TmfTimeGraphCompositeDataProvider, TmfTreeCompositeDataProvider).
We are also using them in a downstream project that we are involved as well.
If not, is this something that can be made API, or perhaps a factory that allows an instance of it to be returned without directly making it an API? If this is something of interest I'll create a gerrit/bugzilla.
[Bernd] The initial idea of the data provider factory is that the factory has to take care of handling a single trace or trace sets (experiments). It just returns a data provider that
implements the data provider interface. This can be done by using a composite data provider like (TmfTimeGraphCompositeDataProvider), some other user specific implementation or even inside the data provider that takes care
of the composition or aggregation. Right now, we can achieve these use cases with current API of IDataProviderFactory. We didn't want to aggregate by default in the experiment case, because how to aggregate/compose can be different from case to case. The drawback
is that each factory and data provider implementation have to do that and be aware of single trace vs experiment.
I was thinking something like the following added to IDataProviderFactory (or somewhere more suitable?):
[Bernd] I'd like to keep the IDataProviderFactory as lean as possible. Adding these API would also require similar methods for TmfTimegraphDataProvider for time graph
views (Gantt chart) and TmfTreeDataProvider which is the base class and which is used for data trees (just the tree part without graph).
We could provide another factory helper to do what you suggested. Or, maybe it's time
to make the composite classes public API. They have been proven useful. I'm ok to make them API.
/**
* Return a composite {@link ITmfTreeXYDataProvider} from a list of traces.
*
* @param traces
* A list of traces from which to generate a provider.
* @param title
* Chart's title
* @param id
* the provider's ID
* @return null if none of the traces returns a provider, the provider if
* the lists only return one, else a
* {@link TmfTreeXYCompositeDataProvider} encapsulating the
* providers
* @since 8.2
*/
public static @Nullable ITmfTreeXYDataProvider<@NonNull ITmfTreeDataModel> createCompositDataProvider(Collection<ITmfTrace> traces, String title, String id) {
return createCompositDataProvider(traces, title, id, null);
}
/**
*
* Return a composite data provider from a list of traces.
*
* @param traces
* A list of traces from which to generate a provider.
* @param title
* Chart's title
* @param id
* the provider's ID
* @param secondaryId
* The provider's secondaryId
* @return null if none of the traces returns a provider, the provider if
* the lists only return one, else a composite data provider
* encapsulating the providers
* @since 8.2
*/
public static @Nullable ITmfTreeDataProvider<@NonNull ITmfTreeDataModel> createCompositDataProvider(Collection<ITmfTrace> traces, String title, String id, @Nullable String secondaryId) {
return TmfTreeXYCompositeDataProvider.create(traces, title, id, secondaryId);
}
