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

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

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

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

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

br/ Rich

Received on Tuesday, 5 November 2013 08:16:20 UTC