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 Saturday, 2 November 2013 11:39:01 UTC