- From: Rich Tibbett <richt@opera.com>
- Date: Sat, 20 Jul 2013 03:03:42 +0200
- To: Device APIs Working Group <public-device-apis@w3.org>
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