[gst-devel] Notes on the 0.9 API

[Andy Wingo]

Hi Torsten,

On Mon, 2005-11-21 at 21:39 +0100, Torsten Schoenfeld wrote:
> Well, I hope I'm still on time.

Yes, but only because we're a little bit late :-)

> As long as there's a way to know when a callback is never going to be
> called again, everything's fine.  Problems arise when a) there's no
> destruction notification, b) the callback outlives the current function
> call, and c) the involved object is no GObject (no qdata).  In every
> other case I can think of, the issue is solvable.

There are loads of callbacks in GStreamer. Mostly they're for
implementing elements. You can think of GStreamer as having two kinds of
API, one for elements and one for applications. We have not gotten
around to splitting them apart, although it's been thought about (mostly
wrt the documentation).

At this point we see writing elements in something that's not C as a
curiousity. Obviously we're not going to make a pad's chain function a
GClosure.

Anywhere we have a callback in the "application" api, there are two ways
to handle it. 1) make the callback qdata on the object, or 2) make a
GClosure variant. The latter is better for automatic wrapper generation
for most bindings. We can add such API if necessary during the 0.10.x
series, although it would be good to know about such functions now so
that we can add more padding.

> http://bugzilla.gnome.org/show_bug.cgi?id=322069

Thanks, will look at it now.

> Here are the ones I spotted while going through the main headers
> (gnome/include/gstreamer-0.9/gst/*.h):
> 
> gst_event_new_newsegment
> gst_event_parse_newsegment
> gst_event_new_buffersize
> gst_event_parse_buffersize
> gst_ghost_pad_new_notarget

Changing these, sure.

> gst_pad_set_bufferalloc_function
> gst_pad_set_activatepull_function
> gst_pad_set_activatepush_function
> gst_pad_set_getrange_function
> gst_pad_set_checkgetrange_function
> gst_pad_set_getcaps_function
> gst_pad_set_acceptcaps_function
> gst_pad_set_fixatecaps_function
> gst_pad_set_setcaps_function
> gst_pad_proxy_getcaps
> gst_pad_proxy_setcaps

I was going to change these but that would be confusing. You wouldn't
know the difference between a setcaps function (which is a function set
on an instance), gst_pad_set_caps (a generic method which might call
setcaps), gst_pad_set_set_caps (a very confusing name), etc. In this
case we try to preserve the 'noun' aspect of these functions, so that
"getcaps function" makes you think of the function itself, whereas the
two verbs in e.g. gst_pad_set_get_caps_function would lead to confusion.

That's the intent anyway -- I think we would confuse ourselves too much
if we changed them.

Regards,
-- 
Andy Wingo
http://wingolog.org/