why KDEMM?

[i]Short Version[/i] [list=1] [*] a higher level API is a good thing to have and it facilitates the integration of media capabilities into all kinds of programs [*] no lock-in to one specific media framework [*] choice (support special needs - like if we'd decide on gst only and accessibility wouldn't work with it but with another framework...) [*] independent from ABI changes in the media frameworks [/list:o] [i]Long Version[/i] [b]1. High Level Multimedia API[/b] This is a thesis that is completely independent from the choice of multimedia framework: Providing a high level API for multimedia will facilitate the development of multimedia enabled applications. To have a Qt/KDE style multimedia API is a good thing for KDE. Why do we see so few applications with multimedia capabilities in KDE? I believe it's because it's not clear what API/library to use, and hard to understand how to use them. The entry barrier to using multimedia in your application is very high. Providing an API that is similar in style to what KDE developers are used to and limited in scope, so that it doesn't take a few days of studying the concepts, will solve those two problems. Ideally a KDE developer would only need to look over the API and already start to grasp how this thing will work. [b]2. No Lock-In[/b] Let me start with a little bit about KDE history and what we learned from it. As you all know KDE uses aRts since KDE 2.0 as it's soundserver and media framework. It was a good decision at that time as there was no other project that could compete with what aRts was able to accomplish for the desktop. So KDE integrated aRts as it's way of doing multimedia. But over time other framework emerged and aRts didn't catch on. So now (in KDE 3.x times) we're seeing more and more KDE applications implementing their own way of "doing multimedia" - what I mean with that is: they write an abstraction of the playback functionality they need and implement it with one or more media frameworks. Two prominent examples are JuK and amaroK. (You see that application developers already (on a small scale) write an API like KDEMM.) Of course it is a good thing that we have those apps, but KDE is missing out a chance for better integration and cooperation of media applications. The idea of adopting aRts was to have a central framework that enables the applications to "just work" and the user to control the applications to their liking (well, that's mostly about routing and volume controls). Basically, what happened in the KDE 2 and 3 releases was a lock-in to the aRts way of doing multimedia, if you wanted to reach the highest degree of integration. With KDE 4 we are able to break the lock-in from aRts. But why would we now want to create a new lock-in with gstreamer? Yes, I agree, that at this point in time using gstreamer seems the most sensible choice. But who can guarantee the future? NMM, for example, seems to have a bright future ahead. And Helix is a choice I wouldn't want to rule out as well. Xine and mplayer both do a very good job at playing back any kind of media file you through at them... That leads me to my next point: [b]3. Choice[/b] Knowing our users (and knowing a few Linux users that don't like KDE because of aRts) giving them the ability to choose their mediaframework will enable some people to use KDE in ways better suited for them. Let me draw a scenario: KDE 4 ships with KDEMM defaulting to the gstreamer backend. Now a user wants his desktop to integrate into the NMM network he uses at home (or set one up with his KDE desktops) and can then choose NMM as backend. [b]4. Independent from ABI Changes[/b] Consider this: KDE 4 ships with a gstreamer backend for gst 0.10. A few months later 0.12 comes out and breaks BC. A "hard dependency on gst" would make KDE 4 depend on 0.10 until the end of the 4.x cycle. But using exchangeable backends we can just release a new backend for gst 0.12 and nothing breaks (if the backends are behaviour compatible - which pretty much is a requirement for all backends).