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

On Fri, Jul 19, 2013 at 2:10 PM, Rich Tibbett <richt@opera.com> wrote:
> 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].

There seems to have been general consensus on this mailing list in
favor of this change so I have gone ahead and updated the WebIDL and
associated algorithms in the NSD API specification accordingly. The
latest editor's draft is available in the usual place
(https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html).

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.

Received on Tuesday, 23 July 2013 08:46:08 UTC