Streams features moving forward

[Chris Dickinson]

Hey, all! I'm Walmart Labs' Node core contributor.

I just finished a recap of what I've been up to over the course of June, and what I'll be getting involved in in July -- specifically, I'll

be working towards ownership of the streams subsystem. I wrote a post detailing possible upcoming changes to streams, and I'd 

love to get your thoughts on it.

Thanks very much,

Chris Dickinson (twitter: @isntitvacant, github: chrisdickinson)

[greelgorke]

this looks awesome! especially the stream of streams (i'm so waiting for this) and the channels (finally we can propagate the errors)

[Bruno Jouhier]

No need for an object sentinel. Undefined is good enough. Allowing undefined values in streams is looking for trouble as they don't even serialize to JSON.

Otherwise streams API is way too complex and should be redesigned with simple continuation callbacks: data = read(cb).

[mscdex]

On Monday, July 14, 2014 7:02:08 PM UTC-4, Chris Dickinson wrote:

I just finished a recap of what I've been up to over the course of June, and what I'll be getting involved in in July -- specifically, I'll

be working towards ownership of the streams subsystem. I wrote a post detailing possible upcoming changes to streams, and I'd 

love to get your thoughts on it.

I can't say I'm a fan of the "multi-topic" streams.

One thing that has kind of irked me about streams2 is/was the behavior of .read(). It'd be nice to be able to just pass in a number of bytes and a callback, then if (and only if) that many bytes are read, then callback is called and pass a Buffer of that many bytes (no more, no less).

[greelgorke]

current streams are implicitly multi-topic: the 'error' event is in fact a topic