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

[Geneviève Bastien <gbastien@xxxxxxxxxxxx>]

Hi Alex,

On 07/31/2013 01:39 PM, Alexandre Montplaisir wrote:
> On 13-07-31 11:52 AM, Geneviève Bastien wrote:
> > Hi there,
> >
> > Here is a first patch for review of this feature:
> > https://git.eclipse.org/r/#/c/14935/
> >
> > 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...).
> Hehe, it's not that I don't like extension points per se. But more often
> than not, extension points are used where plain polymorphism could do
> the same job, in a simpler way.
>
> There's still some discussion to do around this, before we dive head-on
> into refactoring the whole code base... Personally, I find the whole
> "generic pluggable analysis modules with inter-dependencies and such" to
> be waaaay over-engineered, at this stage. We should start with something
> small, and as we discover new use cases we can iterate on it.
>
>
> Here's what I had in mind, which is smaller in scope, but I think can
> cover the use cases you and the people at Poly are trying to do. Of
> course, this is just an idea among others, perhaps the end result will
> be something in between ;)
>
> - Have the "analysis" become the new "view". So replace the View
> extension point with an Analysis one.
>    - An analysis specifies which trace type it supports (so the framework
> knows, from a given trace, which analyzes are available).
>    - The analysis determines which outputs it has (views, command line
> printouts, files, etc.)
>    - The analysis controls all its data-gathering requirements. So stuff
> like building state systems, doing requests, etc. If needed it can
> dictate the order in which it runs those (wait for a query to be
> finished before starting the next one, etc.)
Actually, that's about exactly how it's been implemented ;-)  No code 
refactoring at all (or else a little line here and there) and a number 
of the lines of this commits are taken by comments and file headers, 
it's really not that big a change!
> > 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)
> I would still put the Analysis in the .ui plugins. Command-line output
> is still a UI. If you have absolutely no output at the end, then why run
> an analysis at all?
Really?  I guess my idea of the .ui plugins is "that big thing 
containing all heavy eclipse user interface stuff", so I don't really 
see a simple text output as being a UI.  I guess I'll wait to see how 
the command line will work out before worrying about it.
> > * 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.
> I disagree. I prefer having the views "inside" the analysis. By having
> generic analyzes and generic views at the same time, it increases the
> "degrees of freedom" of the system, and everything ends up being more
> confusing. Not sure if the gain is really worth this added complexity.
> This is where polymorphism could do the job, without the need for an
> extension point. If you want to add a view to an existing analysis, you
> can just extend it and implement your view as part of your new extended
> analysis.
I guess we'll need at least a third opinion on this.  I think the little 
added complexity is worth it to keep modularity.  Anyway, I'll leave it 
as it is for now, with a list of string ids of views. Some of the things 
Florian is implementing these days may bring us an interesting use case 
to see how to go about this.

Looking forward to some in person discussions on this topic ;-)

Geneviève