[mpris] [RFC] MPRIS2 Release Candidate

[Alex Merry]

  On 07/08/10 23:39, Ian Monroe wrote:
>> - i am not a particular fan of using integers for bit flag fields/enums
>>   on D-Bus. I think it is usually much nicer to use strings for
>>   enums. And bitfields should probably be just seperate bool
>>   properties. modern bindings such as gdbus optimize this nicely and
>>   retrieve all flags with a single call.
> Bit flag fields seem more straightforward to me for capabilities.

I sort of didn't respond to this in my other email - I don't really care 
either way, but the player interface would have a large number of 
properties if we split it up.

>> - simplify the version stuff. One version counter should be more than
>>   sufficient. There is no need for major+minor. Also, why do you need
>>   both the version stuff ad the capabilities stuff? choose one. Finally,
>>   I think versioning should be done via interface names and
>>   suchlike. See http://0pointer.de/blog/projects/versioning-dbus.html
> Major is for breaking old clients, minor is for adding new features to
> the API. Why is dbus so much more different then a normal library
> versioning?

Well, D-Bus interfaces are meant to specify a set of methods.  If 
there's an incompatible change, in reality it is a different interface.  
Therefore should have a separate interface name.  I see the logic in that.

I think the minor version is still quite useful.

>> Also, I wonder how this actually relates to the grilo dbus apis? also,
>> the mediaserver dbus spec seems similar a bit too (if only for the track list
>> part). There might be a good opportunity to reuse existing interfaces or
>> at least make the interfaces feel similar in style.
> I wasn't familiar with either of those. Could you link to their DBus
> APIs? Google is failing me with the too-generic mediaserver and
> Grilo's page doesn't make it obvious where the spec is. I see it
> mention Rygel, so it is a system for sharing collections as opposed to
> controlling a running playlist. Maybe MPRIS should drop its ability to
> handle multiple playlists since thats getting quite collection-esque.
> (Or whats the use case exactly?)

We should possibly remove that from the 2.0 spec and introduce it as an 
optional extension later, when we've figured out what exactly we want to 
achieve with it (I, for one, am not sure quite what the purpose of it 
is).  I mean, it can still live in the org.mpris namespace and make use 
of the tracklist interface, but I'm not sure it belongs in the core 
mpris spec.

And we could always re-introduce it in a minor revision if we think it 
does.  It's optional anyway, so there's no sense tying our hands 
immediately.

Alex