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


> From: ext Jean-Claude Dufourd [mailto:jean-claude.dufourd@telecom-
> paristech.fr]
> 
> 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. 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.

My current instance of NetworkServices might not be up-to-date - as in it might not contain the latest new service(s) - but all the services contained in it are still valid and I can still use them in the same way that I did before receiving the onservicefound event. (On the other hand, the web app would be wise to handle the onservicelost event right away because otherwise it would be holding on to stale information.)

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

The same can be said of an onservicefound promise. If in processing the promise I found that the new NetworkSevices object does not contain more services than my original NetworkServices object, I can also deduce that a service has been hidden from me.

To resolve this privacy concern, maybe it would be better for the UA to obtain user permission *before* dispatching the onservicefound event / resolving the promise?

I don't have a strong inclination as to promise vs callback. I only want to be sure that the arguments used for or against either are fair arguments.

- Cathy.

> 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.
> Best regards
> JC

Received on Monday, 4 November 2013 23:26:57 UTC