- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Tue, 27 Oct 2015 08:41:11 +0000
- To: public-web-nfc@w3.org
I agree that in 95+% of the cases there will be one adapter. However, the policy you suggest is too obscure. Probably hard to formulate as exact algorithmic steps, but beyond that I am more scared of letting developers and users deal with all possible combination of errors that may occur with various scenarios of I/O and radio races, without any slight hint where it went wrong. IMO that would bring a really bad user, and developer experience. A priority list like external, internal, and then (if ever needed) a selection dialog for any other case would make it very clear to the user which adapter to use. Also, when something goes wrong, both users and developers know where and what happened. If there is one adapter, or even when there is one internal and one external adapter, this works as well as your proposal, and covers a tiny bit more use cases, say 99+% of them :). Indeed we'd lose the ability to handle concurrent writes and reads across all connected adapters, but I doubt we have a use case for that. Quite the contrary, with NFC use cases (and not only payment, though it's in future versions) you want to be certain which adapter you are using. Also, it leaves an open path forward to support adapter selection on user demand, while keeping the simple interface which was the primary goal after all. -- GitHub Notif of comment by zolkis See https://github.com/w3c/web-nfc/issues/67#issuecomment-151414904
Received on Tuesday, 27 October 2015 08:41:13 UTC