search

intel / dleyna-renderer

dleyna-renderer is a library for implementing services that allow clients to discover and manipulate Digital Media Renderers. An implementation of such a service for linux is also included
https://01.org/dleyna/
GNU Lesser General Public License v2.1
16 stars 19 forks source link

Implement org.freedesktop.DBus.ObjectManager to export the list of discovered DMRs #76

Closed em- closed 11 years ago

em- commented 11 years ago

The org.freedesktop.DBus.ObjectManager interface does the same job that GetServers()/FoundServer/LostServer do, but in a more standardized form.

I'm not sure if implementing it on the server side using GDBusObjectManagerServer can be done without some reworking of the current connector interface, but at least on the client side it would allow me to use GDBusObjectManagerClient, simplifying the current code and likely improving perfromances.

Thanks!

markdryan commented 11 years ago

I'm afraid it doesn't really make sense to use the ObjectManager interface with the dLeyna components. The problem is that when you use ObjectManager you retrieve all properties on all interfaces for every object and we want to avoid doing this. The issue is that not all properties are cached and retrieving uncached properties will result in SOAP requests, which isn't ideal if the client using ObjectManager isn't interested in the uncached properties.

For example, let's assume that you are using dLeyna-server to write a DMP. The first thing you need to do is to display a list of DMSs. If your DMP used ObjectManager to retrieve a list of server objects, dLeyna would need to issue a SOAP request for each DMS to retrieve the org.gnome.MediaContainer2 and the the org.gnome.MediaObject2 properties. However, none of these properties are needed in the server list. We only need the FriendlyName and maybe the iconURL which are cached properties of the com.intel.dLeynaServer.MediaDevice interface. The org.gnome.MediaContainer2 properties are only needed when the user clicks on a DMS to browse it or search it. So using ObjectManager here would generate excess network traffic, making the DMP's UI less responsive.

Now, this is not a problem for dLeyna-renderer as it currently caches all properties. However, I don't think we want to have different object discovery methods for dLeyna-renderer and dLeyna-server. Also, it will be a problem soon as we add new interfaces to the DMR objects to support additional UPnP services such as DeviceManagement. The properties for such services are only needed by a very select group of applications and so we don't want to force all dLeyna-renderer clients to retrieve them.

markdryan commented 11 years ago

Updated the comment above. I hit the wrong key a couple of times.

markdryan commented 11 years ago

We should probably rename GetServers to GetRenderers though. I think the signal names need changing too.

lferrandis commented 11 years ago

I read carefully the specification and it's not mandatory to implement the ObjectManager on all subtree interface. It's a preference, but we can implement it for only one subtree.

I think we could implement it ONLY for the MediaDevice interface. This resolves the problem of caching in dleyna-server. We don't need to return the whole MediaContainer/MediaItem tree of the server (that could be really huge).

And it also match the need of this issue description ("does the same job that GetServers()/FoundServer/LostServer do, but in a more standardized form.")

And the size of data to be returned is reasonable: List of MediaDevice with all MediaDevice properties.

markdryan commented 11 years ago

I read carefully the specification and it's not mandatory to implement the ObjectManager on all subtree interface. It's a preference, but we can implement it for only one subtree.

I don't see where this is written in the specification. To me it clearly states that the intention of ObjectManager is to allow applications to retrieve all properties for all interfaces for certain objects in a single call. It also states that this does not make sense for some services and that those services should not use ObjectManager. I believe the dLeyna services fall into this category. The specification does not oblige us to expose all objects via the ObjectManager interface but if I understand correctly, if we expose an object via this interface we are obliged to include all of its properties for all of its interfaces, so I don't see how we could use this for DMSs or DMRs without completely redesigning our API.

I think we could implement it ONLY for the MediaDevice interface. This resolves the problem of caching in dleyna-server. We don't need to return the whole MediaContainer/MediaItem tree of the server (that could be really huge).

I think this would be a bit weird as apps would need to use one method of retrieving properties for the MediaDevice interface and another for retrieving properties from the other interfaces. Also, as far as I can tell this would really go against the spirit of the specification.

em- commented 11 years ago

DBus upstream confirm that ObjectManager is not for us, unless we split the object path hierarchy: eg. have /com/intel/dLeynaRenderer/server/0/device and /com/intel/dLeynaRenderer/server/0/container providing different interfaces instead of just /com/intel/dLeynaRenderer/server/0 providing both.

em-: """Applications SHOULD NOT export objects that are children of an object (directly or otherwise) implementing this interface but which are not returned in the reply from the GetManagedObjects() method of this interface on the given object. """ em-: so no, if you don't want to download the whole tree at once, ObjectManager is not for you em-: if the MediaContainer's children are in a different object-path subtree it could work I suppose... em-: e.g. /namespace/Server0/MediaDevice0 and /namespace/Server23/MediaDevice42 are MediaContainers, and each MediaContainer has contents like /namespace/Media/Track666 or /namespace/Server0Media/Track666 (replace /namespace with /com/example/MyProject/DLNA or something as appropriate