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


> From: Chan Cathy (Nokia-CIC/Boston)
> 
> > 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.

Scratch that. I misunderstood your proposal. Please ignore the above point.
- Cathy.

> 
> 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 Tuesday, 5 November 2013 03:16:54 UTC