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

Tue Mar 16 11:30:09 CET 2004

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?

>From the list of items you feel are not there yet, the only one I that
it is clear to me might cause API breakage to fix is the clocking, and
even then maybe we could solve it by adding the new 'perfect' clocking
API on the side in order to avoid breaking the old API?

Christian

On Tue, 2004-03-16 at 16:49 +0100, Benjamin Otte wrote:
> Disclaimer: Everything said below is my personal viewpoint and does not in any 
> way represent the opinion of GStreamer as a project.
> 
> I don't think GStreamer is ready for primetime. It's very far, but it's not 
> done. This if nicely shown by the release number, which is still smaller than 
> one and indicating a beta release. I would even say it's still quite far away 
> from done. We have clocking issues to figure out, our thread safety is flaky 
> at best, autoplugging is breaking left and right and schedulers don't even 
> know themselves what they are doing. And that's only the core issues.
> 
> If anybody asked me when GStreamer will be ready, I'd answer it'll probably 
> take a considerable amount of time given the current workforce. Keep in mind 
> that a media framework requires a lot of work - I like to compare it to widget 
> sets, and we're certainly understaffed for something like that.
> I guess people will focus on bringing stability in media playback to GStreamer 
> in the next months and probably won't work on the issues outlined above. (I've 
> recently mailed the list about the stuff I intend to hack on.) So I guess 
> we'll focus on bringing media players like Totem and Rhythmbox in a workable 
> state for the Gnome 2.8 release. After that we'll probably start hacking on 
> the core again and do the missing stuff. If I look back at the transition from 
> 0.6 to 0.8 - which everyone agrees was too short - it took a bit longer than a 
> year. But I wouldn't bet that the resulting API is already release quality. 
> That depends on how much people get done in that timeframe. Anyway, even if it 
> is ready and everything works well, I'd bet it's more than two years and not 
> less.
> 
> I'm not very enthusiastic about maintaining stuff I don't work with in my free 
> time, especially not if I consider them beta quality or worse. API/ABI 
> stability issues certainly are part of stuff I don't work with. And if I look 
> back, there weren't many people working on 0.6 after we started 0.7. So I 
> wouldn't bet anyone being committed to a API/ABI stable release the moment 
> it's no longer cvs HEAD.
> And underlining David's comment: I don't think media framework APIs are 
> researched well enough to request API stability for 3 years either.
> 
> Now there's another thing to think about:
> What are KDE/GNOME really looking for? A media framework or a media playback 
> engine? The way I see it all multimedia features required right now that are 
> considered to be part of a DE's release are playback of audio/video and event 
> sounds. In fact there's not even a "serious" application I know of that uses 
> much of GStreamer's feature set - apart from some small apps like gst-editor, 
> marlin or Andy's Guile hacking. Without a video editor, composing program, a 
> streaming server or anything that really pushes GStreamer more than just "play 
> this file", how will we ever find out if the APIs we invented are good enough 
> for the stuff we imagined they do?
> I think all the DEs want is a playback engine. Inventing a playback engine 
> (like GstPlay or KDE's player) that can play a file sounds good enough for the 
> next release. Maybe make it pluggable, so you're not even forced to stick to 
> one framework. Wait for the apps that really push the frameworks before you 
> decide on one.
> 
> Benjamin
> 
> 
> 
> Quoting Scott Wheeler <wheeler at kde.org>:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Tuesday 16 March 2004 0:09, David Schleef wrote:
> > 
> > > What is a major release cycle?  3.2->3.3, or 3.0->4.0?  If it's
> > > the latter, I don't think there's much possibility in GStreamer
> > > actively maintaining the stable branch that would be used in 4.0
> > > until 5.0 comes out.
> > 
> > It's the latter.
> > 
> > > That could be potentially be several years. 
> > > Given the current state of multimedia frameworks, I don't think
> > > it's wise to even _want_ a stable ABI for that long.
> > 
> > Yes, it would be years.  It looks like the time from KDE 3.0 -> KDE 4.0 that
> > 
> > will be roughly of 3 years.  Both KDE and GNOME regularly keep ABI stability
> > 
> > for that time frame.
> > 
> > aRts -- for all of its faults has kept a stable ABI since KDE 2.0.  (And 
> > during some of that time development actually was active.)
> > 
> > > That being said, I hope GStreamer in 1 year is in the state where
> > > we can be comfortable with a long-term ABI.
> > 
> > Well, we're probably 15-18 months from a KDE 4.0 release.
> > 
> > I guess there are a few notes here -- first, this *is* very important and
> > does 
> > take a long term commitment from the folks here.  This doesn't mean that the
> > 
> > current version has to stay with the same API for three years, but it does 
> > mean that KDE will stick with a single API throughout a major release time 
> > frame and there is the expectation that said release will be maintained.  
> > "Fixed in HEAD, but it doesn't matter for you for 2 years..." won't work.
> > 
> > I've seen debates on this for Gst before.  But I'm really surprised that
> > GNOME 
> > doesn't have similar requirements for the 2.x series (though I would guess 
> > that GNOME 3 is significantly closer than KDE 5).  My personal experience 
> > with APIs is that sticking to an API can be annoying, but that it forces a 
> > certain shift in mindset that brings about code maturity (when all of the 
> > sudden you can't just redesign because you did the last iteration on a whim 
> > and got it wrong).  Sometimes living with mistakes (and realizing that you'll
> > 
> > have to) can really help.
> > 
> > This decision of course isn't up to me, but it will be an important factor in
> > 
> > KDE or other large projects' adoption of GStreamer.
> > 
> > - -Scott
> > 
> > - -- 
> > The three chief virtues of a programmer are: laziness, impatience and
> > hubris.
> > - --Larry Wall
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.1 (GNU/Linux)
> > 
> > iD8DBQFAVjxMQu0ByfY5QTkRAsZLAJ452z31M/JIlmdkmoKNXQ3Fzmzx0QCgr8PQ
> > 28+oZKTxFr0/NncCVgFSsRA=
> > =tKVl
> > -----END PGP SIGNATURE-----
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id70&alloc_id638&opÿick
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> > 
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel