[mpris] [RFC] MPRIS2 Release Candidate

[Lennart Poettering]

On Sun, 08.08.10 00:06, Alex Merry (kde at randomguy3.me.uk) wrote:

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

And where's the problem with that? 

Also, I don't count that many props then...

If you are afraid of too many props then you should check if you can
drop some of them, not try to somehow merge them all into one
super-property. That's just ugly. Normalize variables, don't hide them
in some complex types. It makes introspection more difficult. 

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

Well I am not so sure about that. What would that encode? Revisions of
the implementation? But how useful would that be given that their can be
many different implementations?

In general I believe that it is much smarter to check for specific
features then for specific versions. As such I'd rather say that an
version integer like this should be avoided, to ensure that people check
for features (i.e. whether an interface is implemented or not) instead
of a version.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.