[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] Analysis API next version
|
Hi all,
For those interested, here is the hangout link for the Analysis API
meeting: https://hangouts.google.com/call/iheqyan6izcj3bas7wed7rwyaie
Regards,
Geneviève
On 20/07/16 11:47 AM, Genevieve Bastien wrote:
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
_______________________________________________
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