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

On Thu, Feb 6, 2014 at 1:18 PM, Jean-Claude Dufourd <
jean-claude.dufourd@telecom-paristech.fr> wrote:

>  This is a reminder of an issue discussed before, waiting for Rich's
> opinion
>

I stated my view on this proposal previously:
http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0032.html

> What is intended to be a convenience feature here turns out to be
> quite ambiguous in my opinion.

I also stated my view on ISSUE-130 in a couple of DAP conference calls:
http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-0002/minutes-2013-07-24.html#item05
http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-0048/minutes-2013-08-21.html

I also don't think supporting the ultimate wildcard ("" or "*") is a valid
use case for this API either. The NSD API is about targeted communication
toward networked services that are _well-known in advance to a developer_.
It's not about hoovering up anything that is available in the network if
that process makes communication with collected networked services
ambiguous for developers.

If something has changed in this proposal since those discussions then it
would be good to discuss the specific changes made further.

br/ Rich


> Best regards
> JC
>
> Le 24/10/13 17:48 , Jean-Claude Dufourd a écrit :
>
> 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.
>
> ====================
>
> 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 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
>
> ====================
>
> Best regards
> JC
>
>
>
> --
>   [image: 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
>
> [image: Site web] <http://www.telecom-paristech.fr>[image: Twitter]<https://twitter.com/TelecomPTech>[image:
> Facebook] <https://www.facebook.com/TelecomParisTech>[image: Google+]<https://plus.google.com/111525064771175271294>[image:
> Blog] <http://jcdufourd.wp.mines-telecom.fr>
>