[mpris] [RFC] MPRIS2 Release Candidate

[Ian Monroe]

2010/8/10 Mirsal Ennaime <mirsal.ennaime at gmail.com>:
> 2010/8/10 Rémi Denis-Courmont <remi at remlab.net>:
>> ----- Message d'origine -----
>>> Hello and sorry for the late reply:
>>>
>>> On Sat, Aug 7, 2010 at 8:20 PM, Lennart Poettering
>>> <lennart at poettering.net> wrote:
>>> > A few comments:
>>> >
>>> > - please use the recently standardized property change signals when
>>> >  properties change. Don't cook your own signals.
>>>
>>> This definitely should be done, but i don't think it is a good idea to
>>> switch to it now, as it is not yet ubiquitous in bindings and it would
>>> require to completely rethink a large part of the spec.
>>>
>>> IMHO, we should stick with the legacy signals in v2 and use
>>> org.freedesktop.DBus.Properties.PropertiesChanged signal in v3 (along
>>> with other disruptive changes you are suggesting)
>>
>> PropertiesChanged may be new. MPRIS2 is even newer for it is not out yet, not to mention implemented. I would understand rejecting a dependency on a still evolving spec. But Propertieschanged is done.
>
> Bindings which generate code from introspection data will probably not
> be able to handle these signals.
> As signals which indicate changes in the media player state are a
> critical part of the mpris functionality, using PropertiesChanged
> would mean that applications which use these bindings would have a
> hard time using the mpris.
>
> Switching to different dbus bindings or working around this looks much
> more complex than merely meeting an additional dependency.

These sound like good reasons to never use PropertiesChanged.

Ian