- From: Rich Tibbett <richt@opera.com>
- Date: Tue, 23 Jul 2013 18:45:40 +1000
- To: Device APIs Working Group <public-device-apis@w3.org>
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