RE: [discovery-api] NSD and promises, questions


> From: ext Jean-Claude Dufourd [mailto:jean-claude.dufourd@telecom-
> paristech.fr]
> 
> Le 31/10/13 03:26 , Rich Tibbett a écrit :
> > 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.
> 
> About exploring, I have implemented that and tested it. It is very clean from
> the author's perspective.
> 
>  From a theoretical perspective, onserviceavailable is closer to a promise than
> to an event, in the sense that it happens once and then the whole structure
> is updated. 

I don't think this is necessarily the case. The onserviceavailable event (which has been renamed to onservicefound) is dispatched whenever a new service is found on the local network, and can be dispatched any number of times. While most web app would respond to the event by re-invoking getNetworkServices and get a whole new structure (thereby rendering the event a one-time occurrence), a web app can also choose to not re-invoke getNetworkServices right away but continue using the existing NetworkServices object (e.g. if it's in the middle of tasks it might want to defer the getNetworkServices call until it's less disruptive to the user). Callbacks/events can accommodate both models while promises won't.
- Cathy.

> Events are for situations whith multiple calls. For example, UPnP
> event subscription should stay with callbacks, whereas onserviceavailable
> could become a promise.
> 
> >
> >> 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?).
> 
> Thank you for that link to ProgressPromise. It was close to what I wanted at
> some point, but now I am closer to opponents of that proposal:
> while there may be a need for a new abstraction for event/progress, it
> should be different from promise.
> 
> Best regards
> JC
> --
> Télécom ParisTech <http://www.telecom-paristech.fr>  *Jean-Claude
> DUFOURD <http://jcdufourd.wp.mines-telecom.fr>*
> Directeur d'études
> Tél. : +33 1 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://jcdufourd.wp.mines-telecom.fr>
>

Received on Monday, 4 November 2013 20:34:07 UTC