Re: Updates to NFC spec ...

Hi Dave,

Sorry for not being able to attend. I just got a thorough debriefing 
from Jacques, I'll try to give a shot at it while it's still fresh.

- Regarding the use cases, they should be completed, and also possibly 
link to other documents or to a relevant location in the NFC wiki, 
something similar to what the telephony API does.

- Errors should be explicitly listed and clarified.

>
> In particular, he suggests dropping the powered and polling properties,
> and clarifying the error conditions. He asked what is the use case for
> powerOn without polling? If there isn't one you could make power on
> implicit with start polling.

I'm okay with dropping the powered and polling properties, and also to 
make explicit that a startPoll should trigger a powerOn. Now if we don't 
use the powered and polling attributes, an app should for instance first 
do a startPoll, and begin its work in the resulting promise fulfill 
callback, not in the onpollstart handler that would not be triggered if 
the hardware was already polling.

Symmetrically, powerOff should trigger a stopPoll. So  should we get rid 
of powerOn / powerOff altogether ? I believe the NFC hardware could be 
"powered" but not "polling", when used for secure elements. Having said 
that, we may get rid of it and have it back in some other form related 
to S.E. if the need arises for it.

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

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

Cheers

Luc

Received on Tuesday, 19 November 2013 17:56:54 UTC