Re: [linuxtools-dev] Tmf: a model to support new trace analysis types

[Geneviève Bastien <gbastien@xxxxxxxxxxxx>]

Hi there,

Here is a first patch for review of this feature: 
https://git.eclipse.org/r/#/c/14935/

My main issue is to hook the views to the analysis.

> > Initially I proposed one extension point
> > org.eclipse.linuxtools.tmf.core.analysis having attribute "provided
> > views", but that should be really two extension points, as some quick
> > prototyping clearly pointed out:
> >
> > * one for the analysis itself, which logically goes in to tmf.core,
> > describing the type and class of the analysis.
> > * one for the views it provides, used by tmf.ui to populate the list
> > of analysis and available TmfView (maybe all outputs in general?)
> Do you need the views in the extension points? Couldn't the view simply
> have a getter that returns the list of views? A bit like we do for state
> systems and statistics provider for traces, so we don't need to put
> those in the extension point.
Alexandre, I know you're not hot at the idea of adding extension 
points.  I'd like to know why because I don't see how else to do it than 
with those 2 extension points (I tried...).

Here's the problematic:

* Analysis are core concepts, they can be executed from command line, 
and have default outputs, like text outputs, .dot files for graph, etc.  
Therefore analysis need to be in the .core plugins (and .core plugins 
must not depend on UI stuff)
* Views are only Eclipse or RCP ui objects.  They are just a friendly 
and cute way of representing whatever the analysis did to the trace data.
* Views are associated with an analysis, but analysis couldn't care less 
about the views.  So there shouldn't be a getter/setter for the list of 
views.
* One could implement an analysis and someone else can later add a view 
to it, in a totally different module and that should be possible.  Or 
generic (parameterisable) view could be used to display data an analysis 
happen to provide.
* I tried adding an optional interface IAnalysisViewable that the 
analysis need to implement (it's in the patch), but then analysis still 
need the UI stuff.  Otherwise, they can just return a list of string id 
of views, hardcoded because they don't have access to the UI module, 
with the problems that may cause...

So here's why I think we need the second extension point to associate an 
analysis with a view.  Any other idea how that could be done, given the 
previous constraints?

Cheers,
Geneviève