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

Would ProgressPromise be suitable for the following scenario:

1. A user agrees that a web app can always get informed of the process of a given set of services if they are available.
2. The web app calls the NSD API
3. The browser immediately sends back the matching pre-agreed services
4. The browser shows an info bar in case the user wants to disclose other services to the web app
5a. The user starts interacting with the pre-agreed services (no need to interact with the infobar)
Or
5b. The user clicks on the info bar to disclose other services.

This design would allow zero-click access to pre-agreed services (helping data minimization in a sense) while still enabling user to extend the set of disclosed services.

Regards,
 Youenn

> -----Original Message-----
> From: Jean-Claude Dufourd [mailto:jean-claude.dufourd@telecom-
> paristech.fr]
> Sent: samedi 2 novembre 2013 12:39
> To: Rich Tibbett
> Cc: Device APIs Working Group
> Subject: Re: [discovery-api] NSD and promises, questions
> 
> 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. 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 10:33:02 UTC