[gst-devel] requested pads

[Andy Wingo]

On Sun, 2004-01-25 at 21:27, Benjamin Otte wrote:
> - REQUEST pads exist as long as someone keeps a reference to it. The
> element itself doesn't keep a reference. Normally the only reference is
> the peer pad, so the pad goes a way when unlinking.

This is, of course, not how it works. I think the way it is is the
correct solution, as well. Under what circumstances would we want a pad
without a parent? The whole idea is absurd except in initialization.
Even then I'd argue that gst_pad_new (parent, name, direction) should be
the proper incantation.

Unless there is a compelling example of the viability of pads without
parents, it would follow that the pad can only exist while the parent
exists, and thus the parent should hold the sole reference on the pad,
in all cases. (The refcounting strategy is similar to GtkTextMark in a
GtkTextBuffer -- see the docs on this one.)

The "reference" gained by get_request_pad is only implicit, not an
actual g_object_ref. So the way to release this reference is to call
release_request_pad.

That's how I see it anyway. I could be wrong. But special-casing
reference counting for request pads is sure to cause problems later.
It's difficult enough to "prove" anything will work in GStreamer, and
this would complicate matters. Let's punt the responsibility to the
calling code, where (IMO) it belongs.

-- 
Andy Wingo <wingo at pobox.com>