[mpris] [RFC] MPRIS2 Release Candidate

[Johannes Sasongko]

Hi Alex,

> Why do we have SetRate and SetPosition, but Shuffle, Loop and Repeat?  We
> should be consistent here.

For the sake of readability, please make all of them Set*, not the
other way around. :-)

On a similar note, maybe Prev should be Previous? Not sure why it
needs to be shortened.

> Rate: is this intended to be an actual multiplier?  So that 0.5 means
> half-speed, 1.5 means 1.5 seconds of track are played every second, etc?  I
> think this would be best.

I'm sure that's the idea, considering the description in the "Rate − d" section.

> In this incarnation, there is no reason to use GetAll.  Which is good,
> because in Qt, for example, it's not possible.

I don't know the arguments for or against this, but just curious--why
is it not possible in Qt?

>> As a result, the traditional track identifiers of URLs and position in the
>> playlist cannot be used.  It is recognised that this may pose some
>> difficulties for media player implementations.  A potential scheme would be
>> to use the URI and, in the case of duplicates, appending a fragment and a
>> number (eg: the second "file:///home/jim/foo.mp3" occurance could be
>> "file:///home/jim/foo.mp3#2", which will keep this track id even if the
>> first occurance is then removed).  Any scheme that satisfies the uniqueness
>> requirements is valid, however, as clients are not permitted to make any
>> assumptions about the value of the track id beyond the fact that it is a
>> unique identifier.

I realise this is just an example, but I reckon using memory address
or some serial number would be simpler (as a nice side effect, they're
normally waaay shorter than URIs).

Regards,
Johannes