Re: [web-nfc] Using streams (#369)

We discussed this earlier, not sure if in an issue, though.
There are pros and cons.

I salute this thinking and would wholeheartedly agree that NFC should just have been a bitpipe, but the NFC Forum made sure it's not. :) NFC has a peculiar way to deal with various content types and some age-old use cases are carved into the specs. It's a fossil that we try to expose to the Web, but if you look at the spec, too large part of it is trying to explain NFC, instead of redefining it in a web'ish way (that we originally meant).

We could indeed think of NFC transfers as streaming, especially if we speak about long transfers, though those are totally impractical (would you hold a device for 10-20 minutes to transfer a large file?). However, most transactions happen fast and data buffers are available, making it near synchronous. 

For the analogy, it would be unidirectional streams (half duplex): SNEP is a request-response protocol.

You could take the current API with a fresh mind and try to force it through the streams API mold, though I am not sure how to adapt the NFC logic of content handling to the streams API.

I think the streams API would be an overkill in this use case, and IMHO people who come from NFC side would find it cumbersome to use, but IIRC @kenchris had some ideas.

We could establish an experimental spec branch for exploring this in the future, but I don't have the bandwidth to do that at the moment.


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

Received on Friday, 11 October 2019 14:39:39 UTC