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

Le 5/11/13 09:15 , Rich Tibbett a écrit :
> On Tue, Nov 5, 2013 at 8:27 AM, Jean-Claude Dufourd
> <jean-claude.dufourd@telecom-paristech.fr> wrote:
>> On 04nov. 21:29, Cathy.Chan@nokia.com wrote:
>>>
>>>
>>>> From: ext Jean-Claude Dufourd [mailto:jean-claude.dufourd@telecom-
>>>> paristech.fr]
>>>>
>>>>    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.
>
> I agree with Cathy that this is not the intended function of this
> event. The rules defined in the spec state that a servicefound event
> should be queued for firing when a previously un-tracked service is
> passed through the 'adding an available service' rule [1].
>
> [1] https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#dfn-adding-an-available-service

I see the difference now, thanks.
Forgive me for thinking the difference is not of major importance in the 
way that this event is actually used.
Cathy's use case of waiting before calling getNS does not convince me 
because it is also possible to wait for multiple conditions with a promise.

>
>>> 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.
>>
>>
>> onservicefound holds no significant information beyond "a new service has
>> been found".
>> Whether it is called once or N times is moot: once it has been called, then
>> you know that your current instance of NetworkServices is not up-to-date.
>
> That 'adding an available service' rule [1] also increments the
> NetworkServices object's 'servicesAvailable' attribute [2]. So there
> is actually a significant difference if you are not firing a new
> servicefound event each time a new service is found in the network
> matching the originally requested network service type tokens provided
> in the associated getNetworkServices() call.
>
> [2] https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#dom-networkservices-servicesavailable

The incrementation can be implemented independently from the dispatching 
of an event. So it would be possible to keep that part with a Promise.

>
>> Turning it into a promise would make very clear that you should not even try
>> to count the number of times onservicefound has been called to obtain
>> information about new services.
>
> You are right because that information is more reliably tracked by the
> UA and available to web apps via the 'servicesAvailable' attribute
> [2].
>
>>
>> Actually, allowing the web app to count the number of newly discovered
>> services "violates" privacy. If you count 3 onservicefound, then get only
>> one new service from the next call to getNetworkServices, then you can
>> deduce two services have been hidden from you.
>> That is bad!
>
> If we are to implement a Promise-based approach you would still seem
> to have the same problem - leaking that more services are available or
> that some services have been hidden from the web page. The difference
> between the currently specified behaviour and your Promise-based
> proposal seems to really be the difference between providing a
> quantitative integer-based indicator (i.e. servicesAvailable) as we
> have now or providing a boolean-type indicator (i.e. via your proposed
> one-time Promise resolution).
>
> There would seem to be more value in providing a quantitative
> indicator than using a boolean. Unless, of course, providing a boolean
> does protect the user's privacy better which I'm not really sure it
> does.

I do not understand your position.
A boolean constitutes less information than an integer.
The difference may be small but undeniable.
However, this is a minor issue.

>
>> So I stand behind my request to make onservicefound a promise.
>> Either that or fix onservicefound as a callback to respect privacy by not
>> allowing the counting of yet unapproved services.
>
> I'm not sure how your Promise-based proposal fixes that. It still
> leaks privacy information but in a less-accurate way.
>
> The question seems to be where we draw the line on privacy here and
> I'm not sure changing the currently dynamic quantitative indicator to
> a boolean-like indicator really protects that further here.

So we have some privacy leak in the draft and in my proposal.
Back to a choice between Promise and callback.
At this time, it seems this is a matter of taste.
As a result, I drop the issue.

I think we should remove the updating of servicesAvailable from the 
draft, because it constitutes information shared without authorization 
by the user, which outweighs the potential usefulness of that field.
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 Tuesday, 5 November 2013 12:56:42 UTC