Skip to content

Conversation

@rekmarks
Copy link
Member

@rekmarks rekmarks commented Nov 6, 2024

TODO

  • Fix test coverage due to migration from v8 to Istanbul for coverage provision
  • Default channels to Json for read/write and no / trivial input validation
    • I could not find a way to do this without compromising type safety.
  • Add multiplexer documentation

Future TODO

  • Use streams for all IPC
    • For the exceptional cases where we need non-JSON IPC, create small "sidecar" modules that handle this traffic, and use streams for everything else.

@rekmarks rekmarks changed the base branch from main to rekm/2-stream-names November 6, 2024 08:19
rekmarks added a commit that referenced this pull request Nov 6, 2024
Ref #218 

Adds consumer-provided input validation to streams in the form of a
function constructor argument. This is necessary in order for streams to
actually enforce the types they claim to read and write. Input
validation only occurs in read streams, because we can simply rely on
TypeScript to write the correct values. If input validation fails, the
read stream will end.
@rekmarks rekmarks force-pushed the rekm/2-stream-names branch from 0618b9f to e6a7cd6 Compare November 6, 2024 12:21
rekmarks added a commit that referenced this pull request Nov 6, 2024
Ref: #218 

Add name param to all stream base classes, for logging purposes. Also
update `BaseWriter` constructor params to options bag.
Base automatically changed from rekm/2-stream-names to main November 6, 2024 12:29
Also tidy up various asynchronous operations in base stream classes.
These were causing promises returned from the stream multiplexer to
fulfill erratically.
Get rid of the `makeChannels()` contrivance in favor of exposing
a singular `addChannel()`. Also expose `start()` function in order to
enable either "manually" draining channels or using the `drainAll()`
method.
Also make `synchronize()` method of duplex streams optional.
@rekmarks rekmarks force-pushed the rekm/stream-epic-3 branch 2 times, most recently from c6c8dff to 2933d09 Compare November 6, 2024 16:55
@rekmarks rekmarks force-pushed the rekm/stream-epic-3 branch 2 times, most recently from cf2a25b to 6992b7e Compare November 7, 2024 05:20
@rekmarks rekmarks linked an issue Nov 7, 2024 that may be closed by this pull request
@rekmarks rekmarks removed a link to an issue Nov 7, 2024
@rekmarks rekmarks mentioned this pull request Nov 7, 2024
rekmarks added a commit that referenced this pull request Nov 7, 2024
Ref: #218 

Adds a new class `StreamMultiplexer` to `@ocap/streams`. A multiplexer
is not a stream itself, but rather a wrapper around a duplex stream. The
multiplexer provides methods for creating "channels" over the underlying
stream, which are themselves duplex streams and may have a different
message type and validation logic.

The multiplexer is constructed in an idle state, and must be explicitly
"started" via the `start()` or `drainAll()` methods. All channels must
be added before the multiplexer is started.

Starting the multiplexer will synchronize the underlying duplex stream,
if it is synchronizable. Therefore, in order to prevent message loss,
callers **should not** synchronize the underlying duplex stream before
passing it to the multiplexer. For the same reason, the multiplexer will
throw if any channels are added after it has started. We could enable
"dynamic" channel creation by synchronization the channels themselves,
but only if there's a clear need.

See tests for example usage.
Removes the JSON constraint for our stream types. Leaves it in place for
Chrome runtime streams, since they actually require this constraint. Now
we are free to send non-JSON data over transports that can handle it.
rekmarks added a commit that referenced this pull request Nov 7, 2024
Ref: #218 

Replaces stream envelopes with multiplex streams. This simplifies
multiplexing traffic over the same underlying transport.
@rekmarks rekmarks closed this Nov 20, 2024
@rekmarks rekmarks deleted the rekm/stream-epic-3 branch November 20, 2024 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants