- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Oct 2015 09:40:09 +0000
- To: public-web-nfc@w3.org
So I have got answer to one of my key questions: do we want/tolerate selection dialog. The quite unanimous answer has been no. We can take that as a group decision. If ever the need arises, it is quite easy to add. The other key question on which we need group decision: in the rare case we have multiple adapters, should the NFC object be bound to only one of them, or allow working with all of them in parallel? In native world, adapters work in parallel. Any of the adapters which get in proximity with an NFC device (peer or tag) will work both on pushing and reading. However, they will have different buffers and will not present problems that we would have with Web NFC if we allowed parallelism. I do not like the narrative that "let's disregard the simultaneous push error mess since it's not likely to happen". That may be fine in an implementation, but not in a spec. We could say in the spec that implementations are free to choose the policy of handling multiple adapters, either by exposing only one of them and make the selection, or by handling in parallel. However, even then the spec should have an algorithm either for selecting an adapter (standardize the priority list), or on how to handle errors. I do not have a good solution for the latter. I have tried to write the relevant push steps and I am stuck. So if you would like to see multiple adapters in work, please specify the push steps. We can give it some time. Unless we can do that with reasonable correctness, IMO we have no other choice than selecting an adapter. We could do that the first time NFC functionality is accessed, either through push or watch calls. Then, we could support reacting to plugged in new adapters by applying the priority list based policy, or just say in the spec the page should be reloaded for applying that policy. Make your choices. -- GitHub Notif of comment by zolkis See https://github.com/w3c/web-nfc/issues/67#issuecomment-151781086
Received on Wednesday, 28 October 2015 09:40:11 UTC