[mpris] working on a 2.0 draft

[Mirsal Ennaime]

Hello Remi,

2010/5/22 Rémi Denis-Courmont <remi at remlab.net>:
> ----- Message d'origine -----
>> So, the changes I'm proposing to discuss for a 2.0 draft version are :
>>
>>  * Correct interface names and object path namespaces
>
> I have not checked the draft yet, so I am not sure what you mean. But I fail to see why object paths should be namespaced. oFono and BlueZ do not namespace their paths, this just fine.
>
> Keep in mind that paths are scoped to bus connections, and methods are scoped to interfaces. Thus only bus names and interfaces need proper namespaces. If two applications (e.g. VLC and Xine) provide the same paths, they will have different connections and hence different bus names. If a single applications provide two distinct interfaces (e.g. org.mpris.... and org.videolan.vlc...), methods calls will be scoped by interfaces, should the object paths be the same.
>
> There is one failure case: if a single applications runs two instance of the same service. But name spaces do not solve that problem anyway. Conclusion: do not use it.

You're absolutely right, well-known object paths, however namespaced
don't do the trick, and they're almost useless. As I wrote before,
this is still a work in progress, open to discussion.

So do you think the multi-instance use case issue is worth being
addressed in this spec ?

If it is, there is a rather simple solution which is not to rely on
well known names and define a method which would return a structured
list of object paths. We can even avoid a d-bus round trip by
consolidating this with the media player identification and the
implemented mpris version.

Anyway namespaced object paths can still help add a little bit more
structure if we come to extend the spec beyond the current three
well-known object paths. Plus namespaces can't do any harm do they ?

Thank you for your insights.

-- 
Mirsal