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

Answering questions from the comment above:

> 1. Contradicting spec text about baud rates - use cases section suggest no restrictions but the struct for opening ports suggest otherwise.

The text around baud rates has been cleaned up. There are no restrictions and the baud rate parameter is required in order to force developers to research an appropriate rate for the device being connected to.

> 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?)

The buffer size is used to inform the browser about how much it should try to read or write from the operating system at once. The browser architecture essentially requires it and the updated specification explains how it is used to set up the streams. I've been in communication with the Streams specification authors and implementers in Chromium and we have discussed better ways exposing the behavior of these kinds of internal buffers through the Streams API. There are some notes in the revised specification.

> 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)

Input and output control signals are defined by the standards such as RS-232. They are non-exclusive.

> 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.)

I've removed the serialNumber field from SerialPortInfo for the time being but there is developer feedback that some identifiers are necessary to both distinguish between identical devices and identify specific device revisions as they might speak different protocols. I will be following up with improvements to this later. 

> 5. "RECOMMNEDED"

Fixed. :)

> 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.

Serial access is exclusive. This is enforced by the operating system.

-- 
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-742786966