- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Mon, 21 Dec 2020 19:38:23 +0000
- To: public-web-nfc@w3.org
> I believe the pending read tuple should be per reader. There cannot be a pending read tuple per reader, since then we would store the promise + reader in the reader, which makes no sense. What we could do in the spec is return to the "activated reader list" internal slot, since the implementation still has that one (meaning the "pending read tuple" internal slot was never implemented). In the Chromium implementation, `NfcProxy` already has a `DCHECK()` guard to not include the same reader twice. So all policies have to be made at `NfcReader` level. This means the NFC spec has not been implemented according how it was specified (internal slot for pending reader at the settings object). `NfcReader` and `NfcProxy` still allow multiple readers, so it goes to the Android side that way. In `NfcImpl`, the `watch()` function it will return an error if the id already exists, so a repeated `scan()` will fail. Therefore the `has_pending_scan_request_` is not needed, but it's an optimization. In the end, the implementation still has the "activated reader list" and tag content will be dispatched to all readers. For now, I will try to align the spec to the existing implementation, but this will need to be cleaned up in the future. That would satisfy the examples of @beaufortfrancois above. -- GitHub Notification of comment by zolkis Please view or discuss this issue at https://github.com/w3c/web-nfc/pull/611#issuecomment-749160348 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 21 December 2020 19:38:24 UTC