RE: [discovery-api][ISSUE-130][ACTION-654] wildcard api

Thanks Jean-Claude for the proposal. I like the general idea. Please find some comments inline.
- Cathy.

> -----Original Message-----
> From: ext Jean-Claude Dufourd [mailto:jean-claude.dufourd@telecom-
> paristech.fr]
> Sent: Thursday, October 24, 2013 11:49 AM
> To: Device APIs Working Group
> Subject: [discovery-api][ISSUE-130][ACTION-654] wildcard api
> 
> Dear all,
> 
> Here is proposed text for ISSUE-130, as part of ACTION-654:
> Propose text for network service discovery to define wildcard api and
> feature detection
> 
> This is modelled against the latest text for getNetworkServices.
> I am very flexible for the name of that function, as well as other aspects of
> the proposal.
> 

I would suggest naming the function such that it is immediately obvious that it is a close relative of getNetworkServices. discover() is so different that people would begin wondering if these are two completely different and unrelated things, which they are not. How about something like getAnyNetworkServices?

> ====================
> 
> promise = window.navigator.discover(fragment)
> 
> Immediately returns a new Promise object and then the user is prompted to
> select discovered network services that have advertised support for a service
> whose type contains the given fragment.
> If the user accepts, the promise object is resolved, with a NetworkServices
> object as its argument.
> If the user declines, or an error occurs, the promise object is rejected.
> 
> The implementation of the discover function is optional, as it requires the
> user agent to monitor the network for device and service announcements. A
> web application may test the existence of the discover function by testing
> whether window.navigator.discover is a function.
> 
> When the discover(fragment) method is called, the user agent must run the
> following steps:
> 
> 1. Let Network Service Promise be a new Promise object.
> 2. Let Network Service Promise's Resolver be the default resolver of
> Network Service Promise.
> 3. Return Network Service Promise, and run the remaining steps
> asynchronously.
> 4. Process: Let services found be an empty array.
> 5. For each available service in the list of available service records run the
> following steps:
> 5.1 If available service's type attribute contains the fragment argument then

We need to be more specific about what "type attribute contains the fragment argument" means. I would say "If the fragment argument is a substring of available service's type attribute ...".

> let matched service equal the value of available service.
> Otherwise, abort the remaining sub-steps and continue above at the next
> available service.
> 5.2 same as 9.2 of getNetworkServices
> 6+. same as 10+. of getNetworkServices
> 
> ====================
> 

Your proposal does not include changes to the rule for adding an available service (Section 8), which is run when a new network service becomes available on the network and the UA updates the servicesAvailable attribute of and dispatches servicefound events to the affected NetworkServices objects. Is that intentional? If so, why?

Also, since the goal of the function is to support "wildcard search", are we aiming at supporting the ultimate wildcard "*"?

- Cathy. 

> Best regards
> JC
> --
> Télécom ParisTech <http://www.telecom-paristech.fr> 	*Jean-Claude
> DUFOURD <http://jcdufourd.wp.mines-telecom.fr>*
> Directeur d'études
> Tél. : +33 1 45 81 77 33 	37-39 rue Dareau
> 75014 Paris, France
> 
> Site web <http://www.telecom-paristech.fr>Twitter
> <https://twitter.com/TelecomPTech>Facebook
> <https://www.facebook.com/TelecomParisTech>Google+
> <https://plus.google.com/111525064771175271294>Blog
> <http://jcdufourd.wp.mines-telecom.fr>
>

Received on Monday, 28 October 2013 21:26:06 UTC