- From: Kenneth Rohde Christiansen via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Feb 2019 13:51:29 +0000
- To: public-web-nfc@w3.org
> * subsequent calls of the push() algorithm cancel the previous invocation and reject its promise with "AbortError". We have this: > If target is "any", run the following steps twice, once with slot set to the value "tag", and once set to the value "peer"; otherwise run the following step once, with slot set to the value of target. > If there are any existing instance of this algorithm running whose target is equal to slot, abort that instance of this algorithm by rejecting its p with "AbortError" DOMException. > * in step 11, run only one instance of the algorithm, with one slot containing the push message, and the target (either 'tag', 'peer' or 'any'). See above quote > * cancelPush() doesn't need an argument any more, it cancels the currently pending push, except if the transfer is already in progress (device proximity detected). Doesn't exist anymore > This proposal would still allow all use cases to write to a tag or push to a device. > This proposal would simplify both the clients and the implementations by not having to deal with a parallel condition, whereas NFC push can only happen sequentially, both from end user point of view, and from the NFC adapter's point of view. This would be as easy as change the above somehow, but isn't this more of a implementation simplification? > -- GitHub Notification of comment by kenchris Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/102#issuecomment-467445481 using your GitHub account
Received on Tuesday, 26 February 2019 13:51:31 UTC