[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] Event requests precedence
|
Hi Alex
I'm all for simplifying and minimizing the number of the added APIs. I
had a look at the patches to see how we could do that, but it doesn't
seem to be straight forward. I don't want to re-design the whole
EventProvider design either. We don't know a new design would be better
and solve all the use cases.
Maybe we need to sit back a bit and see what API we actually need to
achieve the Genevieve's use case. Maybe, we don't need all the
parent-child-accessors in ITmfCompositeComponent and we can live with
just a subset of it. Merging them to ITmfEventProvider could also be
done as you suggested.
/Bernd
On 11/06/2014 02:16 PM, Alexandre Montplaisir wrote:
Hi Bernd,
I would have to look at the code again, but from what I remember, what
disturbed me the most was to introduce Yet Another high-level
interface (ITmfComponent is pretty much as high as it gets!), but only
to work-around a very specific problem regarding coalesced event
requests in certain conditions.
But since this concept of parent-child only applies to event
providers, could this be part of the ITmfEventProvider interface
instead? Or maybe, as new ITmfCompositeEventProvider, which would
extend ITmfEventProvider? That at first glance would feel cleaner imo,
because the "solution" would be isolated to the area where the problem
is.
One thing to not forget, the experiment knows about its traces, but
the traces don't known about the experiment they are part of. To
coalesce a request that is sent by a trace with a request from the
experiment the trace has to know about the experiment.
True, experiments know their children, but traces don't know their
parents. But I had assumed that the "request manager" would have been
able to sift through all the registered components, and itself
identify the experiments (or any other potentially "composite"
component), and then look through its children. If any of those
children was registered directly to the request, it could detect this
relationship and send the events in the appropriate order.
However, looking at the code now, it seems to be the RequestExecutor
that knows about the registered components, not the CoalescedRequest.
So I guess the current implementation doesn't really allow us to do that.
Cheers,
Alex
