[mpris] [RFC] MPRIS2 Release Candidate

[Mirsal Ennaime]

On Fri, Jul 30, 2010 at 7:05 PM, Johannes Sasongko <sasongko at gmail.com> wrote:
Alex Merry <kde at randomguy3.me.uk>:
>> 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. :-)

Ack :)
I should have done this earlier.

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

No reason, except historical ones, I'm changing it to Previous

>> 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.

Yes, It'd be nice If someone can come up with a better wording here.

>>> 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).

Yes, this is the best solution I found to the racy tracklist design problem.

Thanks for your feedback !

-- 
Mirsal