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

I can see some benefits in disclosing services at several times as part of the same NSD API call.
The ability to “disclose services at several times” may be used by a specific UI as presented in my previous mail.
It may also be used to speed-up the disclosure of the services to the web app if no user interaction is needed:
- some services may be in the “discovery” cache, refreshing the network state may take a few seconds.
- “fast to discover” services would be disclosed sooner than “slow to discover” services.
In a sense, that would enable incremental-search UIs, similarly to searching for a file in a file system explorer.

I probably need to read more about what is ProgressPromise.

Thanks,
                Youenn

From: Jean-Claude Dufourd [mailto:jean-claude.dufourd@telecom-paristech.fr]
Sent: lundi 4 novembre 2013 11:59
To: FABLET Youenn; Rich Tibbett
Cc: Device APIs Working Group
Subject: Re: [discovery-api] NSD and promises, questions

This looks orthogonal to ProgressPromise. Promises are independant from the user validation mechanism.
Best regards
JC

Le 4/11/13 11:32 , FABLET Youenn a écrit :

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><mailto: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><http://www.telecom-paristech.fr>     *Jean-Claude

DUFOURD <http://jcdufourd.wp.mines-telecom.fr><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><http://www.telecom-paristech.fr>Twitter

<https://twitter.com/TelecomPTech><https://twitter.com/TelecomPTech>Facebook

<https://www.facebook.com/TelecomParisTech><https://www.facebook.com/TelecomParisTech>Google+

<https://plus.google.com/111525064771175271294><https://plus.google.com/111525064771175271294>Blog

<http://jcdufourd.wp.mines-telecom.fr><http://jcdufourd.wp.mines-telecom.fr>





--
[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>