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

[Geneviève Bastien <gbastien@xxxxxxxxxxxx>]

Hello,

As more and more trace analysis are getting available for TMF, I think 
we should have an easier, more modular way to add new analysis.

From my experience with trace synchronization and execution 
graph/critical path, an analysis typically has to be implemented (a few 
more packages in tmf.core), it provides a view or more (in tmf.ui or the 
trace's .ui plugin), sometimes needs a handler for the project view (new 
classes in tmf.ui) and the trace needs to know about it (modification of 
the trace classes, even the ITmfTrace). tmf.core and tmf.ui are getting 
very crowded.

Here's the analysis framework I'd propose to add new analysis:

In tmf.core:
  * A new analysis manager that handles the content from the extension 
point described below
  * Base classes and interfaces for all analysis
  * ITmfTrace will have new methods to get all applicable analysis for 
a given trace type and execute them when necessary

New extension point "org.eclipse.linuxtools.tmf.core.analysis"
An analysis has
  * class: Class that implements this analysis
  * tracetype: class of the trace it applies to (default: all traces)
  * requires: other analysis modules that are required to run before 
this one
  * automatic: whether to run this analysis when the trace is opened 
(default: false)
  * provided views: which views will be available once the analysis is done
  * icon: to represent this analysis

The project explorer view could show the analysis like this for example:
- My Project
  - Experiments [1]
    - SyncExperiment
      - Trace 1
      - Trace 2
      o Analysis: trace synchronization
        o Synchronization view
        o Synchronization statistics view
  - Traces [2]
    - Trace 1
      o Analysis: Lttng Kernel state system
        o Control flow view
        o Resources view
      o Critical path
        o Critical path view
....

In the long run, the actual state system and statistics could be 
considered analysis types and be refactored using this framework.

Each new analysis can then be implemented in its own standalone plugin, 
with core and ui, which would require only the tmf.core|ui (and the 
plugins containing other analysis it requires of course). The main 
plugins would not require any analysis modules.

I'd like some feedback on the proposed approach.  I know Francis 
Giraldeau has been thinking on this problem as well, mostly on the 
dependencies between analysis.  I think this approach is complementary.

Thanks,
Geneviève Bastien