Sweet, the flamewar has started. :) Christian Schaller, gstreamer-developer extraordinaire has mentioned that he thinks Phonon is a bad idea for KDE. (For those not in the know, Phonon will be a multimedia layer for KDE 4 designed to be independant of the actual audio playing code).
When I saw this, and the reaction that erupted on the Internet, I have to say that I’m very disappointed. Aaron Seigo has already made a good reply. So has Scott Wheeler (JuK’s author). But I still want to add my two cents.
Essentially Phonon’s sole purpose in life is to make it easy for KDE applications to use multimedia, without binding KDE applications to a specific backend. In other words, Phonon doesn’t actually play audio or video, it simply acts as a wrapper around code that does. Code like gstreamer.
Now Christian claims that Phonon will either have to be so high level that no application will be able to use it, or so low level that it is simply a KDE-invented multimedia framework. In other words, Phonon will either be useless, or it will be aRts. The solution to this issue? Just standardize on gstreamer, of course.
Now the reason I’m disappointed: This is so untrue that it’s scary. I can think of quite a few KDE applications that need to be able to do nothing more than play a sound. Kaboodle. KNotify. Half of kdeedu. And this little application I work on called JuK.
Let’s talk about JuK and gstreamer. When gstreamer 0.10 was released, it broke compatibility with gstreamer 0.8. So if any JuK users upgraded gstreamer and removed 0.8, now JuK wouldn’t work. (Yes, I have had bug reports like that). Well, that’s cool. It’s easy enough to add support for 0.10, right?
Well, I think the jury is actually still out. We added 0.10 support successfully (and even removed support for 0.8 in /trunk). But I came across a bug I wasn’t able to fix. I suspect it was due to the fact that gstreamer 0.10’s changes to the event loop meant that we had to do something special in JuK since we are using the Qt event loop. I even asked the gstreamer mailing list. Turns out I did get a response after a couple of days (thanks Wim!), seems the reason is that gstreamer no longer works the same as it used to with the synchronous interface. Fair enough, Wim is right when he says users will appreciate an asynchronous interface. But if this is the kind of work I have to expect when 0.12 comes out, then sign me up for Phonon. :P I mean, JuK does nothing more sophisticated than playing, pausing, and stopping a song. So imagine how hard it would be for e.g. the amarok guys to port from 0.8 to 0.10.
So, what we should be expected to do then? To “standardize” on gst-0.10 and never be able to upgrade due to binary compatibility requirements? Wouldn’t that be ironic… 3 years from now people would be accusing us of forking gstreamer 0.10 after the rest of the world was able to move onto the new hotness, gstreamer 0.12. Of course, we couldn’t move because we had to maintain binary compatibility with software that was no longer maintained, and which no KDE developer was familiar with. Sound familiar?
Or to put it another way, how long will the gstreamer developers guarantee that they will work on whatever gstreamer branch we would standardize on? Either they will develop a new branch and freeze the branch we use for only bugfixes, and thus stop our feature development, or they will continue to add features to the same branch for something on the order of five years. Because that is the very freaking point of Phonon: To be able to allow KDE users to upgrade to kdelibs 4.3 with support for the latest multimedia libraries, while the KDE applications compiled against 4.1 will still work. In other words, we are tired of multimedia libraries, and are divesting that kind of crap to layers like gstreamer. Of course, once it’s possible to move to gstreamer’s next version, it’s not that hard to design a simple layer around other multimedia frameworks. (e.g. aKode, NMM, etc.)
On that note, I still wonder why it’s so hard to maintain binary compatibility when you’re using a C library. It’s doable with C++, and that’s like 10 times harder than doing it with C. ;)
The reason this hurts is because I see all the comments on the people’s blog, accusing us of NIH (Not Invented Here syndrome). And if there is any kind of ironic, bullshit kind of response I like to see, it’s GNOME users accusing KDE of NIH. Forget the fact that aRts has required glib since like arts 1.2. Forget the fact that we’ve supported HAL and D-BUS since KDE 3.4. KDE is only ripping out DCOP and replacing it with D-BUS for KDE 4. I certainly still don’t see any Qt-using code in GNOME or GTK+. And I’ve been railing against people whining about glib on KDE lists for years now, only to get to see this whole flamewar when I get back from work this morning.
So, once and for all, let’s get some requirements and basic facts straight:
- KDE has a strict policy for binary compatibility for kdelibs over the lifetime of a major release. This is nothing new. So either gstreamer will be binary compatible over the life of kdelibs, or it will not.
- From past experience, it will not be binary compatible. So if we finalize on a specific branch of gstreamer, we’re merely replaying the aRts debacle. Not an option.
- So we need some kind of interface to multimedia to prevent this from happening in the future. Obviously it would have to be simple enough to be able to port to the next revision. (i.e. we had good gst-0.6 bindings in kdenonbeta at one point that simply didn’t work when 0.8 came out; too much had changed). Of course, now that it’s simple enough to survive gstreamer upgrades, it’s simple enough to support other MM layers.
- We call this layer Phonon, create a website, and then get bitched at about trying to reinvent multimedia frameworks. Uh, thanks?
I’d love to take up the banner for you Christian, but the plain and simple fact is that we cannot depend on any specific branch of gstreamer. We can’t even depend on gstreamer-ish things (i.e. a Qt wrapper API), because if it’s too tied to a branch it will be useless when the next gstreamer major release comes out. We tried this once for gst-0.6 and it came back to bite us in the ass. It took forever to get gstreamer 0.8 support in JuK due to that.
You mention that GStreamer has always championed the GNOME and KDE should have a common multimedia framework. I agree, but now I tell you this: It will only be possible with Phonon, at least at this point. I mean, yeah, Phonon does stuff other than simply wrap multimedia. But that’s all besides the point, we need something like Phonon even if we were to do nothing more than track gstreamer releases. This is especially true regarding the point that you guys seem to be focusing on, the “what if gstreamer goes away problem”. Yes, I am quite sure that gstreamer will be maintained for the next 5 years. That’s not the issue. The issue is if the same binary compatible release series will be maintained (and not just bug fixes, all the features too, we don’t want some shitty second-rate crap). I don’t believe you guys will do it. And why should you, as it would involve tying your release schedule to KDE’s. That would be stupid.
And finally, it would be nice if, in your criticisms of KDE code that you don’t misidentify what the code is trying to do. Judging by your comments you seem to be under the impression that Phonon would be used against a few different backends simultaneously (i.e. support the best of all worlds). This is certainly not the case. I’m not sure about the exact technical details but I would be surprised if Phonon supported more than one backend per desktop session, let alone per application. So if application developers wanted to require gstreamer, hey, that’s cool, but at least JuK will still work no matter what MM framework the user has.
And that’s not counting the comments left by various users, many of whom I suspect have never opened a code editor in their life. One user said this: “it [Phonon] wants to be an abstraction to provide a uniform API to provide multimedia capabilities, except in the process it is making everything but the most simple of tasks more complex.” But, it is doing nothing of the sort. It is making the easy things easier, and it gives up on the harder things. :-P Another user suggested that instead of writing a 5000 line interface and be done, we should instead be working on helping to maintain all those thousands of lines of glib code that comprise gstreamer. Uh, no thanks, we’ll let Christian, Wim, et al. handle it thank you very much. One users asks why KDE doesn’t just add gstreamer backends (and proves he’s missing the point…). I guess he’s never heard about gst-spc, which Chris Lee and myself have worked on. Really makes someone feel good, to see so much FUD against the desktop environment you’ve been slaving away on for years…
So to conclude, just let me know when you guys are ready to enforce binary compatibility in the release series that you are actively developing for KDE 4’s development lifetime, and I will let you know when it’s a good idea to dump Phonon. :-P