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

Le 28/10/13 22:18 , Cathy.Chan@nokia.com 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-
>> 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?

I am good with 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 ...".

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
JC

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


-- 
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 Tuesday, 29 October 2013 08:36:10 UTC