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

[Geneviève Bastien <gbastien@xxxxxxxxxxxx>]

Hi Alex,

You bring up a good point here: views (more generally analysis outputs) 
and analysis really need to be separated.  Analysis have outputs (like 
the state system files or statistics, or just an object on which more 
can be done) and views are just a convenient way to display it.  With 
the Rcp, it would be useful to have simple text output, .dot files, 
etc.  That's something each analysis module will know and document so 
that end users can generate them in the command line.

So yeah, basically TmfAnalysis would replace the TmfView as commander of 
the analysis squad, since it can live for fun, without views.  Views are 
just a tmf ui concept.

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?)

I hope to have a prototype for this feature by the end of the week and 
start putting the execution graph construction into this framework.

Cheers,
Geneviève


On 07/16/2013 12:01 PM, Alexandre Montplaisir wrote:
> On 13-07-15 04:33 PM, Geneviève Bastien wrote:
> > Hi Alex,
> >
> > Thanks for your feedback.
> >
> > Just to be clear: experiment types and this analysis types model are
> > two different things.
> >   * Experiment types[1] are an extension of the experiment to allow the
> > user to define 'roles' for the traces composing it.  Traces can then
> > be treated differently according to their role in the analyses.
> >   * By analysis, I mean action requiring trace processing and having
> > some kind of output.  They may apply to traces (ex. computation of
> > execution graph), experiments (ex. trace synchronization) or
> > experiment types (ex. Virtual machine-host analyses like described by
> > Mohamad last week).
> Ok, so something like a View then? Right now with TMF being a graphical
> tool, everything is centered around views. You're not gonna built a
> custom state system or custom statistics provider for fun, you build it
> to ultimately populate a view.
>
> So your notion of analysis could "replace" the view, right? Something
> like "for this analysis, you need to build this state system. And then
> populate this view". Or print the results to text. With TMF now also
> available in RCP form, this is a new possibility.
>
> I was wondering why we would want to introduce a new "TmfAnalysis"
> concept in addition to what is already there (in the trace type and the
> view). But if it's to replace the view as the end result, and abstract
> away where the output can go, then that could make more sense.
>
> Lunch time here, I'll catch up on the rest later ;)
>
> Cheers,
> Alex