[gst-devel] linking pads (was: wingo gstreamer: gstreamer/ gstreamer/gst/)

[David Schleef]

On Wed, Mar 10, 2004 at 04:37:35PM +0100, Benjamin Otte wrote:
> Quoting Andy Wingo <wingo at pobox.com>:
> > Their directions are not specified, and they can have incompatible caps.
> > Perhaps we should assert that they not be connected already? This is
> > really a question for the autoplug guys, so do speak up...
> > 
> I'd like to have gst_pad_can_link_filtered as a function that I can throw any 
> two pads at and see if they can connect without having to think about them any 
> more.

Keep in mind that it's not possible to properly test whether two pads
can be linked without actually linking them.  I've tried to keep that
to a minimum while rewriting caps, but it does happen.  Perhaps in
0.9 we can make it even more predictable.

gst_pad_can_link() is used in several places (internally) where it would
nice to have a fast function.  pad_can_link() currently isn't very fast,
since it calls pad->getcaps(), which it often recursive and expensive.
There were more important things to think about at the time, but I
realized it would be nice to have multiple layers of can_link(), each
being more expensive than the previous.  And (at least right now), they
should be called gst_pad_can_probably_link(), to indicate that the link
could still fail.



> > I think that we should assert that gst_pad_can_link_filtered. Anything
> > else would be a programming error. Note that this function can still
> > fail if calling the linkfuncs doesn't work out.
> > 
> This sounds like a very good idea. Just g_assert (gst_pad_can_link_filtered 
> ()); and you don't have duplicated code anymore.

Most application code does not check gst_pad_can_link() before linking
pads.  It's rather silly to have to check if you can do something
before doing something, when the latter can just as easily return
an error.



dave...