Re: [RFC] BasicManagement:2 implementation for rygel

[Jussi Kukkonen <jussi kukkonen intel com>]

On 14 June 2013 16:38, Zeeshan Ali (Khattak) <zeeshanak gnome org> 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" :(