[web-nfc] Simplify the push algorithm to have one target at a time

zolkis has just created a new issue for 
https://github.com/w3c/web-nfc:

== Simplify the push algorithm to have one target at a time ==
The use case for writing a tag or pushing data to a device implies the
 following user interaction sequence with most available NFC 
applications:
1. The user selects the data to be transferred (e.g. file, picture, 
contact, WiFi network, etc)
2. The user agent prepares an NFC message that satisfies the use case 
(transferring a file, picture contact, or trigger connection to the 
specified WiFi network, etc)
3. The user selects the desired operation (write to a tag, or push to 
a device)
At this point NFC polling is started by the user agent for detecting 
tags or devices in proximity, and the NFC adapter must know the 
target: tag, device, or either.
4. The user taps the device to another NFC device. Usually a vibration
 happens to notify the proximity condition.
5. Optionally, the user taps again on the app screen to confirm the 
transfer.  The transfer takes place, and the app notifies about 
success or failure.
6. The user breaks proximity with the NFC device.

Given this sequence, the push algorithm could be simplified as 
follows:
- subsequent calls of the push() algorithm cancel the previous 
invocation and reject its promise with "AbortError".
- 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').
- 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).

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.

While the double slots could be reintroduced at a later version of the
 API if it proves necessary, it would be simpler and better to start 
with one slot. At this point I don't see any broken use cases with 
that.

Please view or discuss this issue at 
https://github.com/w3c/web-nfc/issues/102 using your GitHub account

Received on Wednesday, 27 April 2016 19:46:00 UTC