- 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