Re: [web-nfc] Use addEventListener instead of watch

I am fine with factory methods, but if we wanted constructors it's well possible.

Filters are independent of NFC adapters, so no real need to bind to the nfc object syntactically (only in runtime: when when filters are constructed, implementations/algorithms should do the standard checks for support, secure context/permission etc and throw if there is an issue).

Even if there are multiple NFC readers, we have agreed to have an additional API in the future for enumerating/selecting them for write (currently all of them can read, and any of them is allowed to write, so if they are too close, it might happen to attempt writing a tag from two adapters, which is anyway a deployment problem and should be avoided). So at any point implementations will know how to handle the NFC adapters.

However, the API would be perhaps cleaner with the filter creation under the nfc object, since after this change it would only contain the `push()` (to become `write()`?) method. I suggest keeping the `watch()` name for a factory method of creating read filters. 

```javascript
[SecureContext]
interface NFC {
  Promise<void> push(NFCPushMessage message, optional NFCPushOptions options);
  Promise<NFCReadFilter> watch(optional NFCWatchOptions options);
};
```

Note that `NFCPushOptions` and `NFCWatchOptions` may now include an `AbortSignal` bound to an `AbortController`. The limitatation is to be able to cancel a push only in the way it was created (not like create with `any` and cancel only for peer push). 

-- 
GitHub Notification of comment by zolkis
Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/152#issuecomment-425387745 using your GitHub account

Received on Friday, 28 September 2018 10:02:55 UTC