Why not inherit Stream.DuplexStream?

[Floby]

This is more of a question than a real issue.
It seems that making the ZmqStream inherit from stream.DuplexStream would make things clearer on some points for the user. The fact that zmq is not a neutral transport could be leveraged by setting the stream to objectMode so that it handles objects leaving them untouched (even 0 length buffers/strings).

Is that feasible/useful ?

[Schoonology]

@Floby - This is on my "todo" list, but it's not a high priority at the moment. While I agree that it could make usage more obvious, it could also make things more confusing if the contracts don't line up 100%. zmq-stream predates 0.10 and the finished streams2 API, so I did the best I could to take inspiration from it, rather than follow it.

For instance, I cannot uphold the following statement from Writable.write: "Returns false to indicate that the buffer is full, and the data will be sent out in the future." In the case of zmq-stream, a return value of false actually indicates it will not be sent out in the future. I didn't want to write another queue on top of ZeroMQ, so when I receive an EAGAIN error, I return false, and your data should be sent again in the future. It's left as a responsibility of the user. I'd hate for someone to think this worked the way core Streams are implied to work, only to find they're missing crucial messages.

Does that answer your question?

Forewarning: I'll be a little reluctant to accept patches on this issue for the same reasons. No matter what, I feel I need to spend the time to investigate any potential idiosyncrasies between zmq-stream and core Duplexes myself. Patches will merely be used as reference. I appreciate the energy, though! The Node community is the best I've interacted with by far.