Re: DAP-ISSUE-131: Support UPnP device discovery by Device Type? [Network Service Discovery]

On Sat, Jul 20, 2013 at 2:56 AM, Rich Tibbett <richt@opera.com> wrote:
> On Tue, Jul 9, 2013 at 7:20 PM, Device APIs Working Group Issue
> Tracker <sysbot+tracker@w3.org> wrote:
>> DAP-ISSUE-131: Support UPnP device discovery by Device Type? [Network Service Discovery]
>
>> 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.
>
> Herein lies the rub. The objective of this API is to be able to
> _communicate with obtained networked services_, not simply to be able
> to detect their existence in the network and supply defunct objects
> back to a web app. Being able to detect (potentially proprietary)
> "add-on" services is only really useful if the web app is capable of
> communicating with that given service type.
>
> The current API allows a developer to obtain such "add-on" services if
> they know that service's type up-front. Knowing the service's type
> before obtaining that service is step 1 on the path to being able to
> interact with that service. Step 2 is understanding what API that
> service supports and step 3 is actually writing code to interact with
> that service when it is detected and returned and thus being able to
> interact with that service and thus fulfilling the original objective
> when obtaining that service in the first place.
>
> It's important to understand here that the Network Service Discovery
> API does not support service description (SCPD) lookups as a core
> requirement. That is, in my opinion, a largely defunct part of the
> UPnP Services Architecture specification. Either a developer knows how
> to communicate with a UPnP service up-front or they don't. Learning
> about the actions that a UPnP service supports in real-time, as the
> app is running, is largely uselss until/unless the developer knows
> what do with those actions and how to plug those actions in to their
> web app in real-time. That does not seem to reflect how developers
> interact with APIs on the web today (though I hold out hope that
> intelligent self-describing and self-organising API interaction is
> just around the corner).
>
> The alternative, and the process supported today, is for the web app
> to declare the services it expects to utilize _and is capable of
> communicating with_ up-front in the initial getNetworkServices call.
> From there, the concept of a 'device' can be re-constituted by
> comparing the 'deviceId' attribute, if it is available, on each
> NetworkService object.
>
> Obtaining a bunch of potentially unknown networked services by device
> type that a web app is then not able to communicate with is perfectly
> useless. That seems to be the main benefit proposed by this request:
> searching for X number of services by device type, each with a service
> type that is potentially unknown to the current web app. That may be
> great for getting a bunch of JavaScript objects, each one representing
> a networked service, but if you can't read or write to the provide URL
> endpoint in each object, what is the point in providing them to the
> web app in the first place? On the other hand, if the web app requests
> services explicitly because it understands how to interact with them
> then we have ourselves a useful API.
>
> br/ Rich

I ended up skipping the following sentence, which makes the reference
provided below useful :)

Zeroconf-based NetworkService objects do not provide a 'deviceId'
attribute since there is no concept of a 'device' in that technology
[1]. This proposed change only seems to account for UPnP technology.

> [1] Though there are ways in which this can be done by e.g. comparing
> the host, port and base path of Zeroconf-based NetworkService objects
> against each other. If they match then they may be considered as
> coming from the same physical device (note: that is a different
> definition from a UPnP 'device').
>
>> 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

Received on Saturday, 20 July 2013 01:04:09 UTC