- From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- Date: Sat, 20 Jul 2013 09:56:33 +0200
- To: public-device-apis@w3.org
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