Apparently Aaron had to answer the Why isn’t Phonon useless? question yet again. I guess when something is known for abstractionitis, it deserve that.
What I’m going to rant here though is about abstractions, that claim to be “thin layers” over something else and that makes them “good” because they can switch “backends” easily and then are “more flexible”. In case you don’t know what I’m talking about, here’s some examples: Phonon, XUL, Cairo
The biggest problem abstractions have is the lowest common denominator problem. You need a fallback mechanism if one of your backends doesn’t implement your feature. Most of the time, this fallback mechanism is not implemented, so using it ends up either being a “query capability and only use it if available” dance in applications or it just does nothing and users on weird backends (like BSD ;)) wonder why your application doesn’t work.
And even if you have a fallback mechanism, it often is very suboptimal and behaves wrong when compared to “native” output. Firefox’s awesomebar dropdown still looks totally out of place in GNOME compared to Epiphany’s and sometimes selecting text in cairo-generated PDFs is impossible, because the text was rendered using an image fallback.
Another similar problem is that you have to limit the API you design to the backends. You cannot sensibly make use of a real cool feature if most of your backends don’t support it – or you have to implement it yourself for all the backends. Depending on your choice, you either end up with unhappy users or N times as much work.
In the same vein there’s the problem with additional API burdened upon the user to properly support all backends. Cairo is going to gain the useful feature to mark text as a link or attach the riginal JPEG data to an image, so the PDF and SVG backends can include this information. However, this information is completely useless if you output to the screen.
And finally you’re writing a lot of code – mostly compatibiltiy code matching your API with the backends or fallback mechanisms for their unimplemented features. So you have to ask yourself if the “thin layer” you’re writing is really that thin or if you’d better use the underlying features directly. From my experience the answer usually is to use the underlying feature directly unless the “thin layer” adds some substantial features itself.
60 comments ↓
@Kevin
“Or in the case of Phonon, the developers of the Qt/KDE API could of course mandate GStreamer, but that would put the burden on GStreamer to stay API and ABI compatible for the required lifetime or do feature development on two versions.”
or kde could totally go one backend only and choose xine or mplayer ..completely sidelining gstreamer ..what will gstreamer guys and girls say about that?
.. and this is the situation kde dont want to be at and chose to use phonon to shield itself from 1. forcing its users to use a backend they dont want 2. putting all their efforts in one backend without any guarantees that that backend will always be availabe in a state that will make in convenient to kde as a desktop env and to kde developers ..
gstreamer may sit well with the rest of gnome environment but its just as foreign as any another multimedia backends like xine,mplayer and vlc among others ..
what make people think that if kde4 went with one backend, gstreamer will be the default choice? i have xine as the only backend in my kde4 install ..
there are people out there who do not use gstreamer as their backend of choice, personally,on my system, the best gstreamer can do is at the third place behind xine(first choice) and mplayer(Second choice) ..
gstreamer is not for everbody and i think phonon is making a right move in not forcing anybody into using a backend they dont want ..
Funniest thing with all the whining and NIH accusations regarding GStreamer and Phonon, are that GStreamer are one of the largest NIH examples in FOSS. Before GStreamer was started, there already was a multimedia standard widely used and avaliable for addaption by the Gnome project. But they chose to do a NIH, and start their own.
By all means aRts was not perfect, but instead of helping fix this GStreamer increased the chance that there would be NO great backends. And 10 years later this is still true. Had the amount of work, resources and design improvements applied to GStreamer been spent on aRts, the situation would most likely have been different.
Also funny to consider that one of the main issues applied to aRts at that time, now are one of the hottest developments regarding sound on the open desktop the last year, PulseAudio.
Morty:
GStreamer has very little to do with aRts or PulseAudio in terms of problem space (or otherwise); it was never meant to be a sound daemon or replace one, and doesn’t.
tpm:
No GStreamer and aRts overlap very much in functionality, since aRts was more than a sound daemon. The functional replacement for aRts is GStreamer plus PulseAudio(or dmix, or soundcard with hardware mixing if you like). So aRts did more. But the essential problem space is the same, give the user a good infrastructure to handle sound and multimedia.
And that some of the scope of GStreamer transcend that of what aRts did 10 years past, does not change that. Those capabilities could easily been added to aRts too, as the need become apparent.
@Morty:
aRts was designed as a sound synthesis framework. It did this quite well given the technology of its time. Sound synthesis is only a small part of the multimedia problem space and is also orthogonal to the actual audio output.
We now know that the proper design is to have:
1) a good user space sound server that does just that (and that’s already complicated).
2) have synthesis, decoding, encoding, filters,… algorithms and ways to execute them
3) bind it all together with a multimedia framework.
An analogy is 1) the X server/DRI 2) pixel shaders in the GPU, 3) OpenGL API. Another one: 1) pulseaudio 2) ffmpeg, libspeex, libvorbis, libogg, libx264, libalsa…, 3) GStreamer
aRts mixed 1) and parts of 2) but it was not sufficiently abstracted to move forward and become 3). See also http://www.arts-project.org/doc/arts-maintenance.html for more information.
@mtz:
“or kde could totally go one backend only and choose xine or mplayer ..completely sidelining gstreamer”
That doesn’t change anything regarding my argument. Mandating any specific implementation moves the burden to the developers of that implementation.
“…without any guarantees that that backend will always be availabe in a state…”
This is exactly what I wrote. Not doing an abstraction moves the burden of keeping updated and being stable to the developers of the chosen single dependency.
I am not arguming about the additional bonus of having the option to switch to a better implementation at any time, I am just noting that abstraction is also a way of carrying the load of compatability on ones own shoulders instead of conveniently offloading it to somebody else.
@Holger
Maybe you’re missing that I am not talking about Galago, but about asynchronous desktop notifications.
And? I won’t comment on this much further because it’s way off tangent, it’s merely an avenue to follow to try and tell us how bad KDE is at following all these lovely FD standards and it completely ignores that it isn’t just a case of using three interfaces. Integration is never that simple. You need to know what the other side is saying.
But it seems like KDE people did.
Looks as though they have, which is great, and sometimes it just takes time to do. It’s not that there is no evidence of a commitment to do it. Kind of mutes the point really ;-).
You name some successes, and especially having D-Bus as a common IPC mechanism could help improve things a lot.
The problem I have with Gnome is that it doesn’t really use IPC like KDE does. DCOP, and now DBUS, are very critical to KDE actually working and you can’t get a bigger commitment than that. DBUS use elsewhere is generally very application dependant, but it’s been very, very useful to have an IPC system that can go beyond each desktop environment and allow better communication between subsystems.
@Segedunum and @Holger: You are arguing on a moot point… A Galago interface has been implemented and will be included in KDE4.2 (it’s in trunk). From an architects POV, KNotify now supports outputting to Galago, which could be the accompanying notification desktop applet or the GNOME equivalent. KDE applications get native notification on GNOME, GNOME applications get native notification on KDE.
And yes, I know how incredibly off-topic this is, except that it shows (again) that KDE is willing to adopt GNOME-originated technology.
Cheers Michael, wasn’t sure on the status of Galago or if it was still to be used. It’s nice to know that it’s happening. What’s not so nice is people now picking on the ‘time scales’ that these things are happening.
Excellent post, but for one thing which I have to point out: I don’t think it’s fair to list XUL as a case of abstractionitis. XUL is a toolkit on the same level as GTK and QT. I assume you think of XUL as an abstraction because of it’s ability to use e.g. GTK for rendering when running in a GTK-native environment, but QT can also do that, and so can GTK with QT.
I just don’t see what makes XUL any more of an abstraction than QT or GTK. It’s a toolkit. You might argue that it’s a redundant toolkit, but I don’t see how it’s just an abstraction layer around other toolkits.