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

On 20juil. 02:12, Rich Tibbett wrote:
> 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."
> ]);
JCD: The change I propose also allows to search for a subset of the 
COMMONFRAGMENT:
- null subset= search for all services: if trusted, this allows the 
creation of a generic "service manager" webapp
- search for all upnp or bonjour services, e.g. search upnp services by 
DOMAIN, etc
- search for "flexible service names"
>
> Conflating both discovery mechanisms ignores the underlying issue that
> each of these service types will almost certainly provide different
> API messaging types.
JCD: I definitely did not ignore it.
In my implementation, the underlying UPnP and Bonjour APIs are VERY 
different, and yet there is zero impact of that difference on the 
implementation of this proposal.


>   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.
JCD: Indeed! And that is not a problem.

>
> 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.
JCD: There are multiple examples in computing of communication with an 
"object" the software does not know exactly when written.
DLLs, Beans, web services, etc, come to mind. You are looking for a 
service of a certain form, you need to explore a complex service 
description to see if the service matches your need and you need 
"reflection" to construct a way to answer.
My proposal allows this, and more, for what amounts to less than 50 
additional lines of code, in my implementation.


>
> What is intended to be a convenience feature here turns out to be
> quite ambiguous in my opinion.
JCD: Ambiguous ? How ?
Best regards
JC

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

Received on Saturday, 20 July 2013 07:57:01 UTC