From: John (J. P. <jo...@re...> - 2006-12-05 16:06:21
|
On Mon, 2006-12-04 at 16:27 -0800, Brian J. Tarricone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 >=20 > Mike Melanson wrote: > > Allow me to inaugurate the flame war... > >=20 > > Rafa=C3=ABl Carr=C3=A9 wrote: > >> That would let developers use this interface in their programs, and > >> let their users decide of which media player they wanna use. All > >> about FREEDOM. > >=20 > > I read this as: "Real problems are too hard to solve. Let's create=20 > > different problems and solve those instead!" > >=20 > > :) >=20 > That's somewhat similar to my reaction. I can see a need for a > desktop/player-neutral audio API for things like sound notifications on > certain events, but I don't see why individual media players need to > have the same interface. Users can already choose to use whatever they > want. If I'm just an application that wants to launch the user's > preferred audio player (for example), there are already established way= s > of doing that that don't even require D-Bus. >=20 > Embedding audio/video widgets in applications might be an interesting > use for this. However, this bit is way more complicated than just > defining a common control interface, and varying feature-sets among > different players makes it hard to have real drop-in replacements. >=20 > Really, the only common use-case I can see here is the one mentioned in > the original post: writing a little remote control GUI for Kicker, or > gnome-panel, or xfce4-panel or whatever, and being able to have it > control any media player that supports The Interface. For such a > limited use case, what's the point? >=20 > I'm not trying to say this is a stupid idea, I'm just saying I don't > understand how it would be used by users and/or application developers. > Come up with a decent list of *specific* potential real-world users of > this interface, and then we have a purpose. >=20 > -brian >=20 > P.S. Maybe this should be moved to something like xd...@fr...? > I know I'm only subscribed to one of the lists on this cross-post, and > I have no idea if any of the other three will even go through. Hey guys. My D-Bus filter picked up on this discussion. I would say working with the DAPI (Desktop API) guys at xdg might be the best place for this. Creating a D-Bus interface is not much work. The biggest problem is coming up with a standard interface for at least the most common functions. Why would we need this? Well it gives us a better scriptability story since someone would just have to program to the interface. Also there is a huge point in having common controls for different music apps. One point is we can actually make multimedia keys work out of the box or say the apple remote. Right now you need to configure this stuff or a distro needs to fit it to the default media player. Other reasons for having a similar API is for open source apps like Mugshot (http://mugshot.org). By having a standard way for media players to say I am playing this song now Mugshot can propagate that to your profile page (and that is just the start of what you can do with this). Now I know that may not be compelling to the common geek but to my 17 year old brother that is the coolest thing in the world. All of a sudden with a few lines of code your app is accessible, in ways you control, to the outside world. I often complain that we own (as a collective community) all this code to servers and client apps but we never connect them in interesting ways. The mentality that apps should just stick to their own project and not see a wider world flies in the face of how the community was formed through social interactions. By saying this is not worth while throws away the communities biggest asset which is the community. Now I am not saying there can only be these interfaces. By all means we need experimentation before standards. I am usually the first one up in the room at the OSDL complaining that something or other is too young to be a standard. But it would be nice if the media projects did get together and discuss the possibilities. D-Bus is now 1.0 with ABI/API guarantees and I am going to the Desktop Architects meeting in Portland next week to push it as a standard, so now is the perfect time to start thinking about this stuff. It runs on Linux, *BSD including Solaris and I have been told Mac OSX. Pretty soon we should have a windows implementation also. The D-Bus team is always eager to answer questions if you run into issues. Cheers --=20 John (J5) Palmieri <jo...@re...> |