[Bug 757047] tracer: [API]: add register_hook_for_target.

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=757047

--- Comment #11 from Stefan Sauer (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> ---
(In reply to Thibault Saunier from comment #10)
> (In reply to Stefan Sauer (gstreamer, gtkdoc dev) from comment #9)
> > I think there is still some misunderstanding how the tracer is supposed to
> > be used. The tracer plugins will collect data and stream then. That's it.
> > The code that analyzes the data is supposed to read that from the stream.
> > While the app is running or post-mostem.
> 
> This model does not really work for GstValidate where we do lot of behaviour
> checks at runtime, doing that post-mortem is gonna be really complex and not
> bring much. Also doing that with the current API is not gonna look good
> codewise in GstValidate. Having GstMonitors (which monitor one particular
> object) subclassing GstTracer makes everything clean and nice.

I am aware that the post-mosted analysis is not a good fit for you.

> 
> > The fact that the stream is now part of the gst-debug log is interrim. I've
> > posted this bug a loooong time ago for discussion:
> > https://bugzilla.gnome.org/show_bug.cgi?id=733188
> 
> I do not see how that is related to the subject here.

The idea was that e.g. you run the tracers in process and the analysis
out-of-process or even on a different device. We want to affect the traced
process as little as possible. Right now a trace-consumer that would like to
trace a live app, would need to install a GstLogFunction and out-of-process is
not yet supported. Due to these issues, people will jump to the conclussion
that they need to write their own tracers. This is why I mentioned the ticket.
Why I am back in european TZ we should discuss what you actually want to do :) 

> 
> > If we start filtering in the hooks already, where do we start and where do
> > we stop? I think the filtering should be done in the app. If we want
> > filtering in the hook already we need to rethink the api to be more flexible
> > (e.g. using a callback). Otherwise we're going to add more and more
> > functions here.
> > 
> > So if we want this, what about
> > gst_tracing_register_filtered_hook (GstTracer * tracer, const gchar *
> > detail, 
> >      GCallback func,GstTracerFilterFunc filter)
> 
> That only works if we have the 'target' in the GstTracerFilterFunc prototype
> and we make the function look like:
> 
> gst_tracing_register_filtered_hook (GstTracer * tracer, const gchar * detail,
>                                     GCallback func, GstTracerFilterFunc
> filter,
>                                     gpointer data)

Yes, I've forgot the user_data.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.