I was taking with @nhz2 about how Automa (and presumably other packages) use internals from TranscodingStreams, and how it would be nice to make it stop doing that. However, TS was created by the same author as Automa, and the two packages' internals are entangled. So, for Automa to not rely on TS internals, TS needs to offer these things as API. In particular:
- Access to the
.data field of a TranscodingStream, either as a Vector{UInt8} or potentially Memory{UInt8} going forward
- Get and set the
.markpos and .bufferpos fields of the read Buffer of a stream
- Get the
.marginpos of the read Buffer of a stream
Ideally, the Buffer object can also be obtained so the user can manipulate the Buffer directly.
Another approach is for Automa to stop using TranscodingStreams, and instead use something like BufferedStreams.jl. However, I believe TranscodingStreams might have originally been implemented to support Automa.
I was taking with @nhz2 about how Automa (and presumably other packages) use internals from TranscodingStreams, and how it would be nice to make it stop doing that. However, TS was created by the same author as Automa, and the two packages' internals are entangled. So, for Automa to not rely on TS internals, TS needs to offer these things as API. In particular:
.datafield of aTranscodingStream, either as aVector{UInt8}or potentiallyMemory{UInt8}going forward.markposand.bufferposfields of the readBufferof a stream.marginposof the readBufferof a streamIdeally, the
Bufferobject can also be obtained so the user can manipulate theBufferdirectly.Another approach is for Automa to stop using TranscodingStreams, and instead use something like BufferedStreams.jl. However, I believe TranscodingStreams might have originally been implemented to support Automa.