- From: Dave Raggett <dsr@w3.org>
- Date: Tue, 19 Nov 2013 18:40:58 +0000
- To: Luc Yriarte <luc.yriarte@linux.intel.com>
- CC: public-nfc@w3.org
On 19/11/13 17:56, Luc Yriarte wrote: >> We also discussed the scenario where the browser has several apps >> running concurrently on different Tabs and independently calling start >> and stop polling. In principle, apps could use the onstartpolling and >> onstoppolling methods to recover when another app stopped polling and >> the first app wants polling to be active. > > That's pretty much how it is intended to work. > >> >> However, a simpler alternative is for the underlying NFC manager to use >> a counter that is incremented on calls to start polling, and decremented >> on calls to stop polling unless the count is already zero. The NFC >> hardware only stops polling when the counter is decremented to zero. >> This way an app doesn't have to worry about whether other apps are >> starting and stopping polling. > > That would be okay in a platform where the web runtime owns the NFC > hardware, but I don't think we can just assume it will always be the > case. The web runtime may very well maintain a refcount and all, if > another component uses a lower level API to turn off the hardware, the > web app should still be notified. Couldn't the web runtime aim to turn the hardware back on and restart polling if that is what the web apps expect based on the web rum-time's refcount? If that seems difficult to get right, then won't it also be hard for web apps to deal correctly with the start and stop polling events? >> This doesn't fully solve race problems when two apps respond to tag >> present events and independently write to the tag. In principle, we >> could introduce a resource lock, but we would then need to deal with >> recovering when an app crashes or closes without having released the >> lock or when it simply hangs on to the lock for an excessive time. >> > > Instead of a resource lock I'd rather see the write tag calls serialized > by the web runtime, and the promise of the second and later calls > returning an error. Okay so long as the errors are sufficiently clear. > However, that doesn't solve the case where some lower level component > also writes on the tag. Only thing the web runtime can do is make the > write promise return an error, provided it's aware of that. That seems adequate. I am wondering how we can test these scenarios? Many thanks, -- Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Tuesday, 19 November 2013 18:41:32 UTC