|Sven Slootweg cc302b3247||3 years ago|
|src||3 years ago|
|.gitignore||3 years ago|
|README.md||3 years ago|
|example.js||3 years ago|
|index.js||3 years ago|
|numbers.txt||3 years ago|
|package.json||3 years ago|
|yarn.lock||3 years ago|
Special case: Duplex streams
In Node.js streams, there is a thing called a Duplex stream. This is basically a stream that has an independent readable and writable part, that are not connected together. Like a TCP socket, for example; you send data through the writable half and receive data through the readable half - but the data you receive is not the same data as you sent.
Duplex streams are really just two independent streams that are stuffed into a single object, representing a single resource, like a network socket. And this is how ppstreams treats those - as two independent streams. In ppstreams, there are no Duplex streams, so when converting a Node.js Duplex stream, you will have to do the conversion twice - once for the readable part, and once for the writable part. This can be done with the
Why does ppstreams not have Duplex streams? Because they're surprisingly tricky to implement. They would make the ppstreams specification a lot more complex, and make certain things impossible; for example, a sink stream (writable stream) in ppstreams can return a Promise to signify when it's completely done receiving data, but a source stream (readable stream) needs to return a Promise with the next read value! You can only return one or the other, so supporting both would involve a lot of special logic for detecting what kind of thing is being returned.
Aside from that, they are also just difficult to work with. Developers routinely get tripped up by the difference between a Duplex and a Transform stream, and it's much simpler to reason about your streams code when a separate readable and writable stream don't pretend to be a single stream when they're really not.