- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Sun, 06 Sep 2015 16:42:45 +0000
- To: public-web-nfc@w3.org
Setting a push message means, either to a tag or to a peer (works the same way through this interface) means that the user intends to send data, and needs to physically touch the target. If that does not happen within a timeout, or if there is a connection but it's lost while communicating, then there is an error, and promise is rejected with a timeout. If a subsequent call of pushMessage happens, then the message is updated and the timer reset. There is no "cancellation", since a physical connection/communication did not yet happen. Calling pushMessage during communication is probably a bug in the client code, though theoretically possible, and then we have a race condition indeed - but that is completely up to the client if they want to use it that way, and the existence of a cancel method won't help that (they might choose to not use it). Implementations are expected to treat the communication time a critical section, so that the update of the push message never interleaves with the transmission itself. Basically this is already ensured by the nature of native API's, so I don't see a real threat of a race condition there. IMO we don't need a separate cancel method, just to explain the above in the steps. If that is fine, I will make a new commit in this PR to fix it. Thanks for the observation. -- GitHub Notif of comment by zolkis See https://github.com/w3c/web-nfc/issues/45#issuecomment-138098540
Received on Sunday, 6 September 2015 16:42:49 UTC