[MPRIS] User rating read-only

[mirsal]

On Wed, 2012-05-02 at 10:07 -0400, Charles Brière wrote:
> On Wed, May 2, 2012 at 7:26 AM, Alex Merry <kde at randomguy3.me.uk> wrote:
> 
> > On 02/05/12 11:43, mirsal wrote:
> >
> >> However, rating a track might not be the same thing as simply replacing
> >> the 'userRating' metadata entry (media players might want to mix manual
> >> and algorithmic rating or have multiple sources of rating, see:
> >> https://gitorious.org/xdg-**specs/xdg-specs/blobs/master/**
> >> specifications/FMPSpecs/**specification.txt<https://gitorious.org/xdg-specs/xdg-specs/blobs/master/specifications/FMPSpecs/specification.txt>)
> >>
> >> It might then be a good idea to handle rating separately, perhaps by
> >> using specific a method for that purpose.
> >>
> >
> > Well, media players can do what they want with the value they receive;
> > client should never assume with the MPRIS2 interface that asking the media
> > player to set a value (eg: when seeking) will actually cause that value to
> > be set.  They should be listening to the PropertiesChanged signal instead.
> >
> > I think userRating is fairly clearly "the rating that the user has given
> > this track".  Xesam also has an autoRating element.  I guess we could
> > define values based on FMP as well.
> >
> > We have a more general issue with metadata, which is that Xesam is dead[1]
> > (long live Nepomuk[2]).  The Xesam spec is no longer available online,
> > except some old versions on the Wayback Machine.  I don't know what we want
> > to do about this; we don't want to break compatibility, but there is not
> > really a reference available for adding more "standard" elements (which was
> > the original point of using Xesam).  I guess we can add mpris: elements as
> > and when we feel they are needed, though[4].
> >
> > I should point out that I don't think using Nepomuk is sensible for our
> > purposes, as that is an RDF ontology not really suited for a metadata list
> > like we have.
> >
> > Alex
> >
> >
> >
> > [1]: http://trueg.wordpress.com/**2009/04/29/xesam_vs_nepomuk/<http://trueg.wordpress.com/2009/04/29/xesam_vs_nepomuk/>
> > [2]: http://www.semanticdesktop.**org/ontologies/<http://www.semanticdesktop.org/ontologies/>
> > [3]: http://web.archive.org/web/**20081012050951/http://xesam.**
> > org/main/XesamOntology90<http://web.archive.org/web/20081012050951/http://xesam.org/main/XesamOntology90>
> > [4]: http://freedesktop.org/wiki/**Specifications/mpris-spec/**metadata<http://freedesktop.org/wiki/Specifications/mpris-spec/metadata>
> 
> 
> Would their be a problem using only Nepomuk's terms, not everything around
> it? At least their would be accessible documentation on what form of data
> needs to be passed. Those which would create type issues could keep the
> mpris: instead for compatibility (and maybe add a new Nepomuk way).

Yes, it would break backwards compatibility with previous MPRIS2
implementations, which is the main issue raised by the deprecation of
xesam, whichever solution we adopt (except of course if we do not change
the metadata recommendations but only add missing tags in the mpris:
namespace as Alex suggested ).

Best,

-- 
mirsal 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/mpris/attachments/20120502/6f947b1b/attachment.pgp>