- From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- Date: Mon, 04 Nov 2013 22:27:05 +0100
- To: "public-device-apis@w3.org" <public-device-apis@w3.org>
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. 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! 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 21:26:34 UTC