Re: [w3ctag/design-reviews] Serial API (#431)

Apologies for the delay - I've internally shared a review within the TAG, but never got around to actually posting it here. It's a very crude dump, so if the tone is not friendly - I apologize in advance; these are mostly personal notes. I'm trying to check which of these are fixed in the current fork draft, but leaving these here just so I don't lose it in a long chat backlog again.

Here is the dump:

1. Contradicting spec text about baud rates - use cases section suggest no restrictions but the struct for opening ports suggest otherwise.
2. Do not understand why port's buffer size can be specified when the buffer can only be read opaquely through a stream interface, also what even is the buffer here? (Where is it layered? UART? OS? browser?)
3. Not sure if I understand the flow control flags, and there is no explanation on what their roles are and the mutual exclusivity of the flags. Would be good to know the intent here - in particular why a quad bool instead of string enum. (Which was done for parity bits, oddly enough)
4. I'm not sure if SerialPortInfo should be exposing raw serialNumbers, even if device access was granted under user consent - serialNumbers are awfully unique. Per-origin unique would be acceptable, although I don't have an algorithm to implement that from the back of my head - the other part is when the origin needs to actually know the serial number. (e.g. to know what serial commands to send for different hardware revisions based on serial numbers.)
5. "RECOMMNEDED"
6. Question - is serial access expected to be exclusive (and possibly, only on the current active)? If not this opens up an interesting cross-origin communication channel.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/431#issuecomment-566419859