Re: [discovery-api] Supporting UPnP devices

I have currently a full implementation of the current spec.

The only problem I have is the "name" field, which I implement in a 
non-standard way so that it works in my usage scenarios.

On one hand, this proposal is well designed, and on the other hand, it 
is definitely overkill to solve the only problem I have with the current 
spec.

So no, I am not in favor of this rather extensive change.
Best regards
JC

Le 18/3/13 22:59 , Cathy.Chan@nokia.com a écrit :
> There has been on and off discussion on whether the discovery API should
> support UPnP device discovery by device type. See e.g. [1], [2], [3]. At the
> March 6 DAP call we had consensus to explore supporting UPnP devices in the
> discovery API, and I agreed to take a deeper look at the implications of such
> a change and make a proposal. Below are some key findings that I think are
> worth discussing.
>
> The first thing is I'd assume that we want to continue supporting searching
> for individual UPnP services, in addition to searching for UPnP devices which
> contain UPnP services. By this I mean that a web app would continue to be able
> to search for say a ContentDirectory service and obtain a NetworkService
> object that represents the service, regardless of what UPnP device that
> service resides in. In addition to that, a web app would also be able to
> search for a say MediaServer device and obtain an object that represents the
> UPnP device, which in turn contains a ContentDirectory service. I believe this
> is important as there are "add-on" UPnP services that are not tied to any
> particular device types. Besides, the flexibility may come in handy for some
> web app developers.
>
> The biggest impact in adding UPnP device level support is on the object model.
> The NetworkService interface currently consists of the following attributes:
> * id
> * name
> * type
> * url
> * config
> * online
> and the following event handlers
> * onserviceonline
> * onserviceoffline
> * onnotify
>
> While this works well for both mDNS and individual UPnP services (and DIAL,
> which is a special case of UPnP), it isn't particularly suited for
> representing a UPnP device. For one thing, a UPnP device does not have a
> single url associated with it to send messages. Instead, each of the services
> inside it would have one such url. Similarly, a UPnP device itself does not
> receive event messages. The underlying services do. Thus, a UPnP device does
> not need/utilize the url attribute and onnotify handler. Instead, it needs an
> array of objects that represents the underlying services. So, the difference
> between the desired interface to represent a UPnP device and the current
> NetworkService interface would be
> - url
> - onnotify
> + services[]
>
> Now, if we look at the services objects to be included in a UPnP device
> object, they need a little less than what is provided by the NetworkService
> interface, as some of those would now belong to the parent device object.
> Having them also at the service level would only make it more confusing. Most
> notably, the online attribute and the associated online/offline events belong
> to the parent device. The difference between the desired interface to
> represent a UPnP service *residing under a UPnP device object* and the current
> NetworkService interface would be
> - id
> - name
> - config
> - online
> - onserviceonline
> - onserviceoffline
> (In other words, the desired interface for a UPnP service needs only type, url
> and onnotify.)
>
> My proposal would be to expand the NetworkService interface to add an optional
> attribute for the services array and allow the url attribute to be
> optional/nullable, with the caveat that the onnotify handler would be entirely
> unused when the object represents a UPnP device. For representing the UPnP
> service objects, I would propose introducing a separate interface with only
> the necessary attributes/event handlers instead of reusing the NetworkService
> interface to minimize confusion. The name of the interface would need some
> serious thinking/bikeshedding though.
>
> Once we agree on the object model, most of the changes to add UPnP device
> support should be rather straightforward. However, I do expect to see some
> sub-steps in various algorithms that would look significantly different for
> UPnP
> devices compared with the existing services.
>
> Regards, Cathy.
>
>
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0101.html
> [2] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0012.html
> [3] http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/0003.html
>
>


-- 
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144

Received on Wednesday, 20 March 2013 10:06:18 UTC