[gst-devel] Linking pads in 0.9

[David Schleef]

We need to make a collective decision about how pads work while
linking in 0.9.  Two choices:

 1) Linking succeeds or fails based only on the pad template
    caps.

 2) Linking succeeds of fails based on the current caps of the
    pad.

The benefit of doing 1) is that linking 2 particular elements
will always have the same result, independent of the state or
what else the elements are connected to.  The downside is that
any two elements can be connected merely by putting an identity
between them.

The benefit of doing 2) is that applications find out sooner
if they contructed an unnegotiable pipeline.  They will still
need to check if negotiation failed for some other reason.  The
downside of 2) is that there is additional bookkeeping that
needs to take place during the _linking_ step.

The last point may need a bit of explanation -- in 1), the core
uses existing information (template caps) only.  In 2), it is
required to keep each element updated with the equivalent of
0.8's getcaps() information.  In 0.8, this causes the O(n^2)
negotiation issues with large numbers of elements in a pipeline.
Hopefully the O(n^2) issue can be mitigated somewhat -- adding
N identities can easily be O(n), but worst case is still O(n^2).
When done all at once for an entire pipeline, negotiation should
be O(n).

I'm strongly leaning toward 1), since 2) only provides limited
information at an expensive price.  Moreover, 2) requires app
developers to check twice if negotiation failed, once during
linking and again via a callback.



dave...

-- 
David Schleef
Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux