Re: DAP-ISSUE-130: Enable variety of protocols (e.g. UPnP, Bonour) with protocol independent developer code [Network Service Discovery]

On Wed, Jul 17, 2013 at 11:44 PM,  <Cathy.Chan@nokia.com> wrote:
> On Tue, Jul 9, 2013 at 7:19 PM, Device APIs Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
>>
>> DAP-ISSUE-130: Enable variety of protocols (e.g. UPnP, Bonour) with protocol
>> independent developer code [Network Service Discovery]
...
>> So I propose to allow, as first argument of getNetworkServices, a plain string
>> that is neither starting with "upnp:" nor "zeroconf:", in which case, the
>> service type matching would not be done as exact string comparison, but by
>> testing the inclusion of the first argument value in the service type of
>> discovered services.

> May I suggest "any:" - "look for the xxx service using any discovery mechanism", in the same manner that the upnp/zeroconf prefixes mean "look for the xxx service using upnp/zeroconf discovery mechanism".

The current API already allows the developer to search for multiple
UPnP and Zeroconf service types simultaneously. e.g.

navigator.getNetworkServices([
  "upnp:urn:DOMAIN:service:COMMONFRAGMENT:1",
  "zeroconf:_COMMONFRAGMENT._tcp.local."
]);

Conflating both discovery mechanisms ignores the underlying issue that
each of these service types will almost certainly provide different
API messaging types. To begin with, one will be XML-based and the
other _may_ be JSON based...or Protocol Buffer based or key/value
based. There are also no requirements for the Zeroconf API to match
the actions provided by a UPnP API that shares the same fragment name.
Their sharing the same name may be purely coincidental.

Furthermore, the 'DOMAIN' value in a UPnP Service Type allows two UPnP
services with the same 'COMMONFRAGMENT' part to behave in completely
different ways. At best, the developer would need to check the type of
each returned NetworkService object against a well-known list of
supported types in their web app. If that's the case then it would be
much cleaner to have to call them explicitly, up-front, as the API
currently allows. At worst, the developer will try to communicate with
each returned NetworkService object in the same way, using a common
API, which UPnP/Zeroconf services never share.

What is intended to be a convenience feature here turns out to be
quite ambiguous in my opinion.

br/ Rich

> [DAP-ISSUE-131] http://www.w3.org/2009/dap/track/issues/131

Received on Saturday, 20 July 2013 00:12:36 UTC