Re: [tracecompass-dev] Trace Compass state snapshot exchange format

[Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>]

So basically what you are proposing is to pull out the metadata (node
tree and types) from the interval tree and then have all three.

What is the advantage of doing so vs keeping it as is and making a
diminutive state system then can then be merged or resumed?

On 16-11-08 04:17 PM, Alexandre Montplaisir wrote:
> On 2016-11-08 02:53 PM, Philippe Proulx wrote:
>> ----- Original Message -----
>>> From: "Matthew Khouzam" <matthew.khouzam@xxxxxxxxxxxx>
>>> To: "tracecompass-dev" <tracecompass-dev@xxxxxxxxxxx>
>>> Sent: Tuesday, 8 November, 2016 14:15:04
>>> Subject: Re: [tracecompass-dev] Trace Compass state snapshot exchange format
>> [...]
>> `types.json` and `tree.json` could be merged indeed. However, what I
>> understand from the state history back-end (and concept) is that the
>> association between keys and paths (tree nodes) is an extension (that
>> Trace Compass needs, yes), but this would not be required for other
>> applications. I suppose this is only interesting if this state history
>> API is split from Trace Compass one day. In this case `tree.json` would
>> be a TC-specific file (like CTF packet indexes which LTTng adds to
>> a CTF trace).
>>
>>> Also, will it save the segments in the segment store? this is a valid
>>> issue as we have several (especially with XML) segment stores being used
>>> at this moment. I think we don't want to lose the segments being
>>> created. It may be out of scope though for this rfc.
>> I'm not qualified to answer this. Alex?
> I think it would work well with the history tree as a backend for the
> segment store. Unlike "state systems", segment stores do not have
> attributes, so by splitting the mapping between attributes (aka paths)
> and keys into a separate file, we just skip this file when using a
> segment store.
>
>> [...]
>>> Finally, the 'history.bin' is not really detailed.
> See this as the current *.ht files. The difference we are suggesting is
> to break out the last section of that file (the serialized attribute
> tree), and put those in separate .json file(s) which can then be re-used
> by the statedump.
>
>> [...]
>>
>>> Could you sell me on why these three files are more interesting that say
>>> a json output of the analysis id, the state, and the layout, then it is
>>> the responsibility of the analysis to be able to load its snapshot?
> Yes, it would be the responsibility of the state-system analysis to load
> its own statedump before starting to read trace events. Currently I'm
> aiming to add this logic in the TmfStateSystemAnalysisModule.
>
>
> Cheers,
> Alex
>
>
> _______________________________________________
> 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