> On an unrelated note, I think it might be a good idea to include some<br>> basic capabilities negotiation. <br><br>This was a plan that i had with MPRIS all the way until - it got stopped, by subversion (not the SCM) through GNOME developers who wanted to base a spec on it and never came up with anything, yet i believed it so i didn't work on MPRIS further.

BTW since this is already brought up (additional features of the spec, and I've just brought up that I've already thought of those), if i may ask and regardless that it's about me what's exactly the "madness" portion in "basically mpris just without deadchip madness" in that sentence?

I might be personally interested in what tru meant by that, but this list isn't the place for it so i just would like to know what Amarok and XMMS2 have agreed on so far (?) Also, while you're right that doing something like tru proposed (signing up a draft between 2 parties only so it doesn't take ages) will break the usual intertia involved in such processes when a lot of parties are involved, you aren't afraid that everyone else will basically feel coerced into going with your spec? They may follow, but they might not believe.

This is what Rafael meant (note that he isn't an english speaker and probably not as proficient in pointing things out), when he emphasized the ' "FREEDOM" ' in his initial mail: So we _ALL_ agree on something _HERE_, and no one really feels coerced into something.

<br><br>As he, also, originally pointed out, the spec should be only mostly generic and contain one object on the interface that is meant for player-specific methods; as far as generic capability negotiation goes i agree, in the case of BMPx it's even more complex (and i figure in the case of Amarok, although i'm not 100% sure) since for BMPx, it depends on whether it can go next or not on what it's currently playing (

e.g. there is no "next" when playing a http stream, since we're not 100%-playlist based anymore like Amarok, RB, XMMS (1.2), etc) but it plays directly from the relevant playbacksource). WRT this it might be even needed to do dynamic (playback-control-)caps negotiation/sending out status updates on the interface.

Super-brief overview over the current BMPx architecture: The playbacksources derive from 2 classes: PlaybackSource and UiPart; UiPart is a base class that gives it an interface to communicate with the playershell wrt UI control, and PlaybackSource is a class that provides basic stuff for communicating with the player shell when it comes to playback control: Simple example, you select an album in the albums list, thus you basically can start playback (with no selection in the album list, and the album list being currently visible, you just can't play anything), so the CAN_PLAY caps gets set and emitted as signal to playershell, which then sets the "play" action active. Same things happen for next/prev (more importart wrt the above), since if the app reaches the last item in let's say the playlist, or for an album, there is no next item anymore (usually), and hence the CAN_GO_NEXT caps gets disabled, for one so PlayerShell doesn't even try to go to the next item, and 2ndly so that the controls can be visibly disabled as a hint to the user.

<br><br>(Yeah some people think it's irrelevant whether all actions reflect the current application's state, but i don't.) <br><br>Overview like this:<br><br>[Source 1]  [Source 2]<br>         \               |<br>           \             |

<br>        [        Playershell      ] (Basic/general GUI control, HOSTS: Playbacksources)<br>                         |<br>        [             Core            ] (DBus, application start/stop control, HOSTS: Shell)<br>

                          <br><br>Milosz<br><br><div><span class="gmail_quote">On 12/6/06, <b class="gmail_sendername">Daniel Chokola</b> <<a href="mailto:dan@chokola.com">dan@chokola.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Milosz Derezynski wrote:<br>> Allright as i've read on the transcript, you're going to implement the<br>> DBus interace as a "client" anyway.<br>><br>><br>> So for one: nevermind the part about "DBus or nothing", but then again

<br>> what is your concern with running one player, and debugging XMMS2 the<br>> same time?<br>> Milosz<br>><br><br>That was just an example. but the concern is that someone might want to<br>have a couple clients running at once to different players. For example,

<br>I already use a couple clients to constantly talk to my stereo PC. While<br>in the meantime I run the latest XMMS2 from git to test new features and<br>hack away.<br><br>It doesn't have to be on different machines, either. If two clients are

<br>running on the same machine and both running the same DBus service, will<br>it be possible to control them individually?<br><br><br>On an unrelated note, I think it might be a good idea to include some<br>basic capabilities negotiation. Maybe check that a program can support

playback, playlists, medialib, and metadata. That way simpler media players like VLC can omit things like the medialib. I think this could save a lot of bickering over implementation and watering down of the spec.

<br><br>-Dan "puzzles" Chokola<br></blockquote></div><br>