[mpris] [RFC] MPRIS2 Release Candidate

[Lennart Poettering]

On Sat, 07.08.10 17:39, Ian Monroe (ian at monroe.nu) wrote:

> 
> On Sat, Aug 7, 2010 at 1:20 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Thu, 29.07.10 15:29, Mirsal Ennaime (mirsal.ennaime at gmail.com) wrote:
> >
> >> Hello,
> >>
> >> I would like to propose this document as a mpris 2.0 release candidate:
> >>
> >> http://www.mpris.org/mirsal/2.0-draft/spec.html
> >>
> >> Could you have a look at it and share any remark, concern, improvement
> >> proposal you have in mind ?
> >
> > A few comments:
> >
> > - please use the recently standardized property change signals when
> >  properties change. Don't cook your own signals.
> >
> > - 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.

Well, they are just a set of boolean variables that is written and set
in a weird way. Why not make it what it really is, i.e. boolean variables?

> > - It makes little sense to me that "capabilities" might change. What's
> >  the rationale? CapabilitiesChanged is redundant I believe.
> 
> Some tracks can seek, some can't, start and end of the playlist.

If that's the case then I am not even sure that "capabilities" is the
right name.

I would much rather prefer boolean props like the following:

  CanSeek
  CanPause

and so on. That makes them disocverable via the intropsection and
normalizes their types. Makes it easier to add more flags later on.

> > - 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, because this is kinda guly I'd say. If you want to selectively
support multiple versions use interface names. i.e. o.m.foo1 and
o.m.foo2 as interface names could be selectively be supported for
multiple versions.

> > - i think the track id should be a dbus object path. That's how we
> >  identify objects in dbus. this wouldn't even have to mean that you
> >  expose any interfaces for these objects...
> 
> What is the advantage to this? Having the trackid be whatever internal
> representation that is meaningful and easy to use for the audio app
> makes sense to me.

That you have a normalized way to identify objects? i.e. "typesafety" is
the keyword here.

You can easily generate object paths dynamically.

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

http://live.gnome.org/Rygel/MediaServer2Spec

And regarding Grilo I have no real idea. Might be worth poking them.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.