Re: [tracecompass-dev] Analysis API next version

[Genevieve Bastien <gbastien+lttng@xxxxxxxxxxxx>]

Hi Bernd,


*Tuesday morning* then. It will give a chance to contributors across the 
ocean to be present as well if they so wish.


Geneviève


On 20/07/16 11:32 AM, Bernd Hufmann wrote:
> Hi Genevieve
>
> thanks for initiating this. I have a conflicting meeting at that time 
> on Monday, July 25. What about in the afternoon (1 p.m.) or Tuesday 
> morning?
>
> Please let me know
>
> Bernd
>
> On 07/20/2016 10:13 AM, Genevieve Bastien wrote:
> > Hi all,
> >
> >
> > <tldr>
> >
> > I'd like to have a discussion to gather requirements for the next 
> > version of the Analysis API of TraceCompass: What role will it play 
> > in the future of Trace Compass, what features do you see around it, 
> > what are the limitations of the current API, its advantages, other 
> > thoughts.
> >
> > *When*: Monday July 25, 10h30 Montreal time
> >
> > *Where*: Google Hangout. The link will be sent a few minutes before
> >
> > </tldr>
> >
> > The analysis API was introduced around 3 years ago, to separate the 
> > trace from what one can do with it and visualize it. As such, it was 
> > a success, analyses and views popped everywhere and did not 
> > necessitate touching the core code. With time, it was extended to 
> > support various analyses sources, parameter providers, add 
> > requirements, etc.
> >
> > Lately though, some requirements arose that would require more 
> > ducktape on the API than graceful extension. I think it's time to 
> > review it to be more future-proof. Here are some examples:
> >
> > * List all the possible views (analyses outputs) for a given trace 
> > type: That is not possible because views come from an analyses (not 
> > its helper) and to instanciate an analysis, one needs a trace on 
> > which the analyses apply, so we couldn't see the views for which the 
> > analysis does not apply
> >
> > * Meta-analyses: Some analyses (like currently the critical path) 
> > require the presence of an analysis of a given type. Since all 
> > analyses are created sequentially for a trace, it is not possible to 
> > verify such a requirement, the analysis of the requested type might 
> > not be there yet. That is why the critical path appears everywhere 
> > even though it does not apply most of the time.
> >
> > * "On-demand analyses": lami analyses (to support lttng-analyses) 
> > were introduced recently. They have quite a bit in common with the 
> > current analyses, but they were deemed sufficiently different that a 
> > new hierarchy of classes was added beside the analysis API instead 
> > working with it. That's sad because some concept, like the reports, 
> > can be useful to "normal" analyses.
> >
> > Though it would be possible to solve those problem by changing a few 
> > things here and there, a little re-design of the whole API may be 
> > more desirable.
> >
> > This meeting is _not_ to discuss the API itself. It is just to 
> > discuss the requirements for this new API, its role in the future of 
> > Trace Compass, what it should be possible to do with it, etc. After 
> > that, someone (or sometwo or somethree) can work on a proposal for 
> > the new API.
> >
> >
> > Best regards,
> >
> > Geneviève
> >
> > _______________________________________________
> > tracecompass-dev mailing list
> > tracecompass-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or 
> > unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
>
>
> _______________________________________________
> tracecompass-dev mailing list
> tracecompass-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev