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


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