- From: Rich Tibbett <richt@opera.com>
- Date: Thu, 31 Oct 2013 13:26:14 +1100
- To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- Cc: Device APIs Working Group <public-device-apis@w3.org>
On Wed, Oct 30, 2013 at 1:30 AM, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr> wrote: > The NSD draft has been updated to use promises. > In the process of implementing that version, I am coming up with questions. > > In the newest draft, getNetworkServices returns a promise. > Then the promise gets resolved. > Then if a new matching service is discovered and authorized, the > onserviceavailable *callback* is used. > Then getNetworkServices is called again and returns a new promise, etc... > > The first question is, if promises are supposed to avoid callbacks, why do > we still have callbacks (onserviceavailable, onserviceunavailable) ? > Would it make sense to change onserviceavailable and onserviceunavailable to > promises ? > Old usage: > networkServices.onserviceavailable = function() {...}; > would become: > networkServices.onserviceavailable.then(function() {...}); > It's a good question. Current practice seems to prefer hanging events off 'stub' objects. I haven't seen this type of practice elsewhere Promises are being used. I'm more concerned with having consistency with other Promise-based APIs than anything else right now. It could be good to explore this further. > The second question is, are promises-with-immutable-value-once-set the right > model for NSD ? > It looks like a mutable promise would be better, but I understand from > reading about promises that immutability is an important feature. There has been some discussion around implementing e.g. ProgressPromise @ http://lists.w3.org/Archives/Public/www-dom/2013JulSep/0113.html. I'm not sure that gives you exactly what you want but does perhaps present a similar strategy that could be used. I don't think DAP or the NSD API is the right place to invent such things though (maybe WebApps?). > I am looking for a pattern that is easier to use on the author, as usual. +1. That relates to keeping things simple also. br/ Rich
Received on Thursday, 31 October 2013 02:26:44 UTC