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

Le 28/10/13 22:18 , a écrit :
> 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-
>> 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?

I am good with getAnyNetworkServices.

>> ====================
>> promise =
>> 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 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 ...".

I like your proposed text.

>> 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?

The implementation of discover/getAnyNetworkServices is entirely based 
on the "list of available service records" that the implementation 
maintains. The current section 8 already deals correctly with that part, 
and I felt that no change was necessary. I actually spent a long time 
reading and rereading the beginning of that section to be sure I 
understood all the implications of each sentence (from the previous draft).
Do you think there is something I missed and a change in that section is 
necessary to implement discover/getAnyNetworkServices ?

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

In my implementation, matching "*" is possible (with a "" fragment).
I do not see a (technical/implementation) reason to exclude it from the API.
Best regards

> - Cathy.
>> Best regards
>> JC
>> --
>> Télécom ParisTech <> 	*Jean-Claude
>> DUFOURD <>*
>> Directeur d'études
>> Tél. : +33 1 45 81 77 33 	37-39 rue Dareau
>> 75014 Paris, France
>> Site web <>Twitter
>> <>Facebook
>> <>Google+
>> <>Blog
>> <>

Télécom ParisTech <> 	*Jean-Claude
Directeur d'études
Tél. : +33 1 45 81 77 33 	37-39 rue Dareau
75014 Paris, France

Site web <>Twitter

Received on Tuesday, 29 October 2013 08:36:10 UTC