On 14 June 2013 16:38, Zeeshan Ali (Khattak) <[email protected]> wrote: > Hi Jussi, > >> Christophe Giuraud and I have been working on implementing UPnP >> BasicManagement service for rygel and would like to get comments on it >> and hopefully get the code integrated into Rygel. > > So that was your excuse to not work on Maps. :)
No guilt tripping now. I'll get back to it... >> * Background >> >> BasicManagement:2 service [1] contains a bunch of tools to indicate >> overall device status, perform maintenance functions (e.g. reboot) and >> to run some diagnostic tools (e.g. Ping). Typically this service would >> be running on the same device as a renderer. There is ongoing work at >> DLNA in this area but unfortunately that is not public yet. I will >> post again with more info when that changes. > > I have a question, with rygel being typically run per-user/session on > desktop, how do you make these services work? I haven't looked into > the code but it this a plugin? If so, then it could work. In which > case, wouldn't it be better to keep it in a standalone tree since > typical desktop user won't need/want this and rygel is supposed to be > multimedia-only? It's not currently a plugin -- just code in rygel-core -- but that sounds like a sensible approach. I'll take a look at how it would work. I don't think the fact that rygel is typically per-user/session matters to the "how to make these services work"? It's true that enabling diagnostics by default might not make much sense though, this is indeed more useful for a set-top type device. Keeping this outside the tree is certainly possible as well. The DLNA docs on the subject are apparently now public[1] so here's a bit more details: DLNA has diagnostics guidelines which are a non-integrated part of IEC 62481 (the whole DLNA IOP guidelines). I don't think blindly doing what specs say is a good design philosophy, but I am pointing out that there's an argument for putting the diagnostics into rygel, based on Diagnostics being a DLNA thing: The BasicManagement spec is not media related but the DLNA usage scenarios definitely are. The basic model is this: * user or another system interacts with a local diagnostics app (not defined by DLNA) * app invokes UPnP actions to request diagnostic functions to be run on another device * the results are returned via UPnP * information is presented (not defined by DLNA) The simplest real use case I think is: * DMC has +DIAGC+ (diagnostics controller) capability * DIAGC talks to a +DIAGE+ (diagnostics endpoint) running on a DMR * DMC local UI can ask DMR to run tests (like making sure it can resolve a specific server) and present results I'll get back to you on the plugin approach (which seems even more sensible since I only now realised one of the use cases has DIAGE running on a DMS as well). - Jussi [1] For certain values of "public": DLNA Diagnostics Guidelines can be found in the dlna.org "members area / Published (non-integrated) Guidelines". Unfortunately they still use this friendly disclaimer in every document "Any form of reproduction and/or distribution of these works is prohibited" :( _______________________________________________ rygel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/rygel-list
