Conversation
| proxy.setWritable(decode) | ||
| proxy.setReadable(encode) | ||
| eos(proxy, cleanup) | ||
| const proxy = Duplex.from({ writable: decode, readable: encode }) |
There was a problem hiding this comment.
This requires node 16.8.0 and probably can't be browserified either because readable-stream is behind
There was a problem hiding this comment.
Although, on the browser point, perhaps it's time to let go of the old and build something web stream-based
There was a problem hiding this comment.
Sad but true... to both.
There was a problem hiding this comment.
Can we use Duplex.from if available and otherwise fallback to duplexify?
There was a problem hiding this comment.
A few things I want to do first:
- Benchmark
Duplex.from, I didn't try that yet. And design a more suitable benchmark, because I've focused mainly on iterators so far, less on one-of operations likeput()andget(). And swaplevelformemory-levelto remove fs from the equation. And bypassnetsockets. - Check compat with
length-prefixed-streamwhich usesreadable-streamand therefore doesn't satisfy core'swillEmitCloselogic. Andlength-prefixed-streamhas its owndestroy()😞. Not sure what the effect is though, if any. Can you help with that?
There was a problem hiding this comment.
I need some time to think about which flavor of streams to go with. It's a difficult question.
There was a problem hiding this comment.
I would personally not use readable-stream or any of the non-core helpers in production. But that's just my opinion. IMHO They are basically unmaintained and have lots of bugs.
There was a problem hiding this comment.
Indirectly that unfortunately includes any lib that uses them.
|
Superseded by #7. |
2 participants
I've spent a lot of time sorting out problems with the eos & duplexity packages in core. Please use the core versions. 😄