future of ABIs (was Re: [gst-devel] amarok)

[David Schleef]

On Tue, Mar 16, 2004 at 08:30:18PM +0100, Christian Schaller wrote:
> Well if we are comparable to a widget tookit I don't see why we can't
> work like GTK+ works, who manages to maintain ABI compatability accross
> releases. Why can't we to just add new API and deprecate old ones like
> GTK+ do, but not actually remove the old API's before we are ready to do
> a major version number switch?

The object heirarchy is not the hard part.  The hard part are
things like GstCaps -- in order to ABI-stably change caps, I
would have had to properly migrate GstElement and GstPad to new
object classes.  Once you've decided that you need to change
something like GstElement, you might as well bump the ABI.

The problem at this point in time is that the GStreamer core is
still mostly full of these types of subsystems that need to be
completely rethought and rewritten, which will affect large
sections of code.

A compounding problem is that whenever these systems are rewritten,
somebody loses.  The big loser in the GstCaps change was gst-launch.
You can no longer expect a pipeline created in gst-launch to
always come up with decent frame sizes, rates, etc. -- this was
a conscious decision to give applications more power over choosing
formats, and gst-launch is just dumb about it.

So in a future scheduling rewrite, say, the loser might be loop
based elements or other elements that make it fundamentally
difficult to schedule elements properly.  So if we decided that
loop-based elements were the root of all scheduling evil, we
would still be stuck with having to support them.



dave...