Phonon and gstreamer (KDE developer response)

I saw with interest your article on the objections to Phonon by a gstreamer
developer.
 
I'm a KDE developer myself, and I co-develop the JuK application included with
KDE. For a couple of years JuK has supported gstreamer output, so I think I
have a fair amount of knowledge regarding the interaction of KDE and
gstreamer.
 
So here are my comments:
 
Phonon is designed to solve 2 major issues:
1. A simple API for basic multimedia tasks. i.e. playing a song, playing a
video, maybe visualization. Nothing complex, but enough to make it easy to
add basic multimedia support to applications.
2. Do all of this in a binary compatible fashion.
 
What does this stuff about binary compatibility mean? Well, basically that
the set of libraries that KDE distributes for programmers to develop against
must be binary compatible. That is, if you compile a KDE game against
kdelibs 4.0, and then upgrade kdelibs to 4.1, your KDE game should work with
no recompilation required.
 
Multimedia features should be a part of kdelibs, as they will be shared
between many different applications. So, the KDE multimedia framework must
be binary compatible as well.
 
Why wasn't this an issue with KDE 3? Well, that was because we adopted aRts
as the standard multimedia framework for KDE 3, and made sure it was binary
compatible as well. We could do this because we controlled aRts. Needless
to say, this didn't turn out so well. The aRts developer eventually grew
tired of maintaining aRts. None of us were really familiar enough with the
code to add new features (although we managed to get some small stuff done),
so aRts just rotted.
 
We weren't going to repeat that mistake for KDE 4. People have mentioned that
gstreamer is not going to be abandoned, as it has much more developer
traction than aRts ever did. But that's not the point. People don't realize
that we would have to choose a specific release branch of gstreamer should we
adopt gstreamer. In other words, we're not just stuck with gstreamer, we're
stuck with gstreamer 0.10 (binary compatibility!).
 
This would be fine (in theory) if gstreamer 0.10 were to be the branch that
features were developed against for the lifetime of KDE 4. But this is
impractical for the gstreamer developers. They would be tied to our release
schedule. They wouldn't be able to correct design flaws with
binary-incompatible releases like they have with 0.8 and 0.10 releases.
 
So, it is obvious they would continue to improve gstreamer, probably with 0.12
and 0.14 in the KDE 4 timeframe. But we would still be stuck requiring 0.10.
And then perhaps 0.12 was such a quantum leap above that we decided to add
support for it to kdelibs. Now we require two separate gstreamer versions to
be installed.
 
Now, gstreamer has excellent provisions for installation of different
versions. But that is not what I would call user friendly. Plus it doesn't
account for the case where users upgrade from gstreamer 0.y to 0.y+2 and
remove 0.y, and unintentionally completely break their KDE installation.
 
So if we just rely on gstreamer 0.10, now we're stuck with an abandoned code
base, which KDE developers are unfamiliar with. Does this sound familiar to
anyone? ;)
 
The gstreamer developer recommended developing a Qt/KDE layer directly on top
of gstreamer. This is impractical as well. In fact, we have done it before.
We had a very nice wrapper over gstreamer 0.6 that we used for JuK at one
point. But when 0.8 came out, enough of the gstreamer design had changed
that the gstreamer 0.6 bindings were useless, and couldn't be simply "ported"
over. This left JuK in a bad state, relying on an obsolete gstreamer, until
we finally gave up waiting for bindings, and added the bare minimum of
gstreamer 0.8 support. We also had to do the same thing during the 0.8 to
0.10 transition thanks to changes in the synchronous handling of gstreamer
events.
 
This isn't to blame the gstreamer developers: Both gstreamer upgrades were a
definite change for the better. But the problem is that they were still a
definite change. We won't be able to keep the Qt/KDE gstreamer bindings up
to date, not to mention binary compatible, without limiting the scope of the
API that we wrap. In fact, Phonon is about the extent of the amount of
wrapping we'd be able to do.
 
So basically we have to have some sort of framework to isolate most of KDE
from changes in the underlying multimedia stuff. (Applications that require
more than Phonon can provide would just have to rely on the appropriate
backend directly, but then they're not in kdelibs either). Once we've
developed a framework that can insulate against API changes across gstreamer,
it's not hard to see how to extend that to other backends.
 
I've railed on about this (slightly less politely) on my blog at
http://grammarian.homelinux.net/~mpyne/weblog/kde/phonon-...
 
I think this would be a great explanation for a front page article (sans the
blog link to my home computer ;), as I have seen a lot of misunderstanding
regarding Phonon this morning browsing across the flamewar.
 
Thanks for the great coverage of all things Linux:
 
Regards,
 - Michael Pyne