- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Oct 2015 08:07:57 +0000
- To: public-web-nfc@w3.org
I think the only thing we should do is remove the Note about the microtasks. Specifying what should happen as additional unload steps actually is quite ok. About Section 10.3., I think we could say "no NFC content is pushed, and no received NFC content is presented via watches while suspended, <i>as specified by the pushMessage(link) and watch(link) steps</i>". The rest is defined by the NFCAdapter suspended state and the algorithms for push (and watch). If something is already set, it is not pushed on the next tap. The pushMessage() steps define the exact behaviour in step 13 (.1): if the adapter is suspended before the tap happens, it is not pushed, but if the page is unloaded during a tap, the interrupting the ongoing transfer is on best effort, most likely it is not interrupted. In fact, the spec cannot mandate that the UA guarantees canceling ongoing transfers. Same for cancelPush(). The Promise will tell whether there was success or not (if it manages to complete) so clients can act accordingly. When the state is suspended, timers continue running (on the native side) and the implementation should be able to sort out what to do when they expire vs when the Document is closed. I don't think we should not specify exact Promise behavior in this spec, especially if is not yet completely specified elsewhere. For implementations the important bit is how to handle adapter release (in fact even that is an implementation detail). We will take into account implementation feedback. -- GitHub Notif of comment by zolkis See https://github.com/w3c/web-nfc/issues/57#issuecomment-145776940
Received on Tuesday, 6 October 2015 08:07:59 UTC