- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Oct 2015 11:26:02 +0000
- To: public-web-nfc@w3.org
I agree the spec should list all errors that can occur when rejecting Promises. If we are missing some, please point them out. For security reasons, only foreground NFC operation is allowed. If the page is closed, i.e. the user is not interested any more in Web NFC, IMO the only thing to be done right is cleanup. The lifecycle of NFCAdapter is bound to that of Window. When/if service workers will be supported, this will change. When transfer fails because the user physically broke range, or because a communication error, that case in handled by the spec by rejecting Promise. If the transfer takes too long, and the user does not break range, implementations are not supposed to stop transmission for any reason, and as a matter of fact they cannot: we cannot implement interrupting ongoing transfers. As a developer, you don't need to implement a button calling cancelPush() function, since it is much easier for the user to break range than push a button. IMO this is a non-use-case. Besides, NFC was never meant for 4GB data transfers, but doing handover in that case and do the transfer over WiFi or Bluetooth. 22 hrs long transfers are a non-use-case for the current version of the spec. Future versions may address handover. In #62 I have added a note to cancelPush() steps, in order to avoid misunderstandings. -- GitHub Notif of comment by zolkis See https://github.com/w3c/web-nfc/issues/57#issuecomment-146160407
Received on Wednesday, 7 October 2015 11:26:07 UTC