- From: Mark R. James via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Oct 2015 08:43:51 +0000
- To: public-web-nfc@w3.org
For (1), the API should give developers as much detail as possible on what promise abort situations they have to handle, otherwise they might be making wrong assumptions about the cause of an abort. If it's browser-dependent whether a cancelPush done by the API implementation on unload gets seen by a catch block, then developers should be told that so they can write their code to handle that possibility. My preference is to instead leave the promises pending (no cancelPush), and to state that, so developers don't have to consider the unload case. As for (2), I'm thinking about peer-to-peer. A 4GB max record payload takes 22h to transmit at the NFC data rate, and a message can have multiple records. If cancellation of ongoing transfers by a cancelPush is implementation-dependent, again that should be stated in the API, whose aim should be to minimise developer uncertainty. -- GitHub Notif of comment by mrj See https://github.com/w3c/web-nfc/issues/57#issuecomment-146119758
Received on Wednesday, 7 October 2015 08:43:54 UTC