Re: [discovery] getNetworkServices should return a Promise instead of callbacks.

I support this move, but do not think it is more urgent than other 
change requests
Best regards
JC

Le 19/7/13 06:10 , Rich Tibbett a écrit :
> We should consider adopting a Promise-based approach for the Network
> Service Discovery API instead of holding on to callbacks. This change
> affects one method in the API: navigator.getNetworkServices.
>
> The change would be to replace the WebIDL included in Section 4 [1]
> with the following *much simpler* WebIDL block:
>
> [Supplemental, NoInterfaceObject]
> interface NavigatorNetworkService {
>    Promise getNetworkServices( in any type );
> };
> Navigator implements NavigatorNetworkService;
>
> Where the value of the promise would resolve to a NetworkServices object [2].
>
> Usage may be as follows:
>
> navigator.getNetworkServices("...NSD search
> string...").then(showServices, handleError);
>
> This change would significantly reduce the amount of WebIDL we need to
> maintain in this specification in support of a callbacks model. It
> means implementations can inherit from the web browsers Promises
> infrastructure [3]. Re-using Promises would likely make implementation
> of this API significantly less difficult, lead to more consistency
> across different implementations (assuming each browser implements the
> lower-level Promises API in compatible ways) and leave less room for
> NSD API implementation confusion [4].
>
> What do people think here?
>
> br/ Rich
>
> [1] http://www.w3.org/TR/discovery-api/#requesting-networked-services
>
> [2] http://www.w3.org/TR/discovery-api/#networkservices
>
> [3] http://dom.spec.whatwg.org/#promises
>
> [4] For example, I've seen discussions on this mailing list asking
> e.g. whether success callbacks fire only once or are able to fire
> multiple times against a single call to getNetworkServices(). Promises
> only resolve once and that matches the original intended behavior of
> the successCallback argument to getNetworkServices. Using Promises
> therefore would implicitly re-enforce such assumptions without needing
> to be overly explicit of those intentions in this API itself.
>


-- 
Télécom ParisTech <http://www.telecom-paristech.fr>  *Jean-Claude 
DUFOURD <http://jcdufourd.wp.mines-telecom.fr>*
Directeur d'études
Tél. : 01 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://blogrecherche.wp.mines-telecom.fr>