1. Ok it seems clear now. I was really confused by all the different explanations. So
r.on('readable', function(){ var chunk = null while( (chunk = r.read()) != null ) consume(chunk) }) should work just fine in usual case, right? 2. it's ok, 3. i'm with you here. if you have more than one consumers, then you need a custom forking stream, or go with the old way, pause+attachattach+resume. whatever. 4. i was expecting that. Thank you for clarifications on that topic. Am Dienstag, 7. Mai 2013 20:55:07 UTC+2 schrieb Isaac Schlueter: > > As of current v0.10: > > 1. The first 'readable' event listener will *definitely* get called, > whether data has been pushed into the read queue or not. It will > trigger a read(0) if there is no data in the queue, and will emit > immediately if there is data in the queue. The code for this is quite > clear, actually: > > https://github.com/joyent/node/blob/76cbd03/lib/_stream_readable.js#L668-L680 > > 2. Any subsequent 'readable' event listeners that are added will not > have any magic effects. > > 3. The only reason to have to call read() before adding your readable > listener is if the stream may have been partly (but not entirely) > consumed, and a different 'readable' event listener already added. > (In which case, are you sure it's ok for you to be consuming this > stream? Because it sounds like it might be someone else's stream, and > not yours. Maybe rethink your approach?) > > 4. Yes, you can use `r.on('data', function(chunk) { ... })` > foreverever. It's a part of the API. The new API is a superset of > the old API. Nothing in the stream API has been deprecated. > > Does that clarify things? It seems to me like everything you're > wishing for is actually how it already works. > > > > On Tue, May 7, 2013 at 1:00 AM, greelgorke <greel...@gmail.com<javascript:>> > wrote: > > so the official ways to read a readable are: > > > > 1. Old Style: > > r.on('data', function(data){...}) > > r.on('end', function(data){...}) > > > > works and will be supported (foreverever?) > > > > 2. The new, kindofCbutnotreally, Style: > > var existingChunk = rs.read(); > > //do something with existingChunk > > rs.on('readable', function () { > > var chunk = rs.read(); > > // do something with chunk > > }); > > > > this feels very uncomfortable to me. you can poll all the time, > 'readable' > > event looks to me like an invitation for calling read, but it's not in > the > > first place, because it's emited only when you called read at least once > and > > only if it returned null, right? looks like to much 'ifs' on that for > me. > > looks like bad api design here to me. why is this designed this way? > more > > intuitive would be: > > - attach to 'readable' > > - if there is data already, the listener is called as soon as it's > attached > > ('newListener' event right?). > > - in the listener you can/should consume via .read as long as result > isn't > > null (better undefined, suits some edge cases in object mode better.) > > - end event emited, when stream is done. > > > > 3. The new old kinky way via piping to a consumer stream: > > r.pipe(new CustomWritable()) > > > > this looks pretty to me and hides away the gotchas of 2. but it has > > indirection of dataflow control, wich is only handled by calling the > > callback in _write and tweekin waterMarks. so if you want better control > > i.E. unshifting chunks, then you probably have to stick with 2. right? > > > > Trying to resolve my new confusion about readable. > > > > Greet > > > > greelgorke > > > > > > > > Am Dienstag, 7. Mai 2013 03:49:57 UTC+2 schrieb James Hartig: > >> > >> Just to update this thread for future readers... > >> Talked to Isaac on Twitter and he had said that "readable" will be > fired > >> on first chunk after making a Readable Stream. But before you make the > >> "readable" listener, you can call read() just to be sure there isn't > already > >> data. > >> > >> So: > >> var existingChunk = rs.read(); > >> //do something with existingChunk > >> rs.on('readable', function () { > >> var chunk = rs.read(); > >> // do something with chunk > >> }); > >> > >> On Monday, May 6, 2013 5:45:09 PM UTC-4, James Hartig wrote: > >>> > >>> > The 'readable' event fires as soon as *any* data is added to the > >>> > internal buffer, but only if a previous read() call returned null. > If > >>> > you never got a null read, then you haven't exhausted the buffer, so > >>> > there's no need to emit 'readable', since presumably you already > know > >>> > it's readable. > >>> > >>> Is needReadable set to true when you create the socket or do I have to > >>> call read() right after making the socket? > >>> I looked through the ReadableStream code and couldn't find a path that > >>> sets it to true. I'm using new fs.ReadStream(null, {fd: 4}). > >>> > >>> On Monday, May 6, 2013 4:59:39 PM UTC-4, Isaac Schlueter wrote: > >>>> > >>>> > Basically the loop is because the "readable" event doesn't fire > until > >>>> > the buffer is filled up and if you want to get data immediately, > then you > >>>> > can't rely on "readable"? > >>>> > >>>> The 'readable' event fires as soon as *any* data is added to the > >>>> internal buffer, but only if a previous read() call returned null. > If > >>>> you never got a null read, then you haven't exhausted the buffer, so > >>>> there's no need to emit 'readable', since presumably you already know > >>>> it's readable. > >>>> > >>>> > It would seem (from the docs) that read() without any limit returns > >>>> > the whole buffer, so how would there be more data the next time you > call it? > >>>> > >>>> The length of the returned data from read() is > implementation-defined. > >>>> In objectMode streams, it'll always be one "thing", but in > >>>> binary/string streams it can be any amount of data. > >>>> > >>>> If you're using the stream.Readable base class, then yes, read() will > >>>> always return the full buffer, *unless* you're piping, in which case, > >>>> it returns the top chunk in the list, so as to avoid an unnecessary > >>>> copy in the case where there's more than one chunk ready. > >>>> > >>>> > >>>> On Mon, May 6, 2013 at 11:10 AM, James Hartig <faste...@gmail.com> > >>>> wrote: > >>>> > Sorry to be late to the party... > >>>> > > >>>> > Basically the loop is because the "readable" event doesn't fire > until > >>>> > the > >>>> > buffer is filled up and if you want to get data immediately, then > you > >>>> > can't > >>>> > rely on "readable"? > >>>> > > >>>> > It would seem (from the docs) that read() without any limit returns > >>>> > the > >>>> > whole buffer, so how would there be more data the next time you > call > >>>> > it? > >>>> > > >>>> > > >>>> > On Sunday, April 14, 2013 4:57:49 PM UTC-4, Jorge wrote: > >>>> >> > >>>> >> On 30/03/2013, at 00:56, Isaac Schlueter wrote: > >>>> >> > >>>> >> > ```javascript > >>>> >> > var chunk; > >>>> >> > while (null !== (chunk = rs.read())) { > >>>> >> > doSomething(chunk); > >>>> >> > } > >>>> >> > ``` > >>>> >> > >>>> >> I use to write code like that too but it might break it seems, > look: > >>>> >> > >>>> >> <https://bugs.webkit.org/show_bug.cgi?id=114594> > >>>> >> > >>>> >> this works: > >>>> >> > >>>> >> function works (s) { > >>>> >> var pos; > >>>> >> var n= 0; > >>>> >> var t; > >>>> >> var r= ""; > >>>> >> var o= > >>>> >> "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"; > >>>> >> var p= > >>>> >> "5678901234nopqrstuvwxyzabcdefghijklmNOPQRSTUVWXYZABCDEFGHIJKLM"; > >>>> >> while (n < s.length) { > >>>> >> t= s[n]; > >>>> >> pos= o.indexOf(t); > >>>> >> r+= (pos >= 0) ? p[pos] : t; > >>>> >> n++; > >>>> >> } > >>>> >> return r; > >>>> >> } > >>>> >> > >>>> >> this doesn't: > >>>> >> > >>>> >> function fails (s) { > >>>> >> var pos, n = 0, > >>>> >> t, r = "", > >>>> >> o = > >>>> >> "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ", > >>>> >> p = > >>>> >> "5678901234nopqrstuvwxyzabcdefghijklmNOPQRSTUVWXYZABCDEFGHIJKLM"; > >>>> >> while (n < s.length) { > >>>> >> r += ((pos = o.indexOf(t = s[n++])) >= 0) ? p[pos] : t; > >>>> >> } > >>>> >> return r; > >>>> >> } > >>>> >> > >>>> >> -- > >>>> >> ( Jorge )(); > >>>> > > >>>> > -- > >>>> > -- > >>>> > Job Board: http://jobs.nodejs.org/ > >>>> > Posting guidelines: > >>>> > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > >>>> > You received this message because you are subscribed to the Google > >>>> > Groups "nodejs" group. > >>>> > To post to this group, send email to nod...@googlegroups.com > >>>> > To unsubscribe from this group, send email to > >>>> > nodejs+un...@googlegroups.com > >>>> > For more options, visit this group at > >>>> > http://groups.google.com/group/nodejs?hl=en?hl=en > >>>> > > >>>> > --- > >>>> > You received this message because you are subscribed to the Google > >>>> > Groups > >>>> > "nodejs" group. > >>>> > To unsubscribe from this group and stop receiving emails from it, > send > >>>> > an > >>>> > email to nodejs+un...@googlegroups.com. > >>>> > For more options, visit https://groups.google.com/groups/opt_out. > >>>> > > >>>> > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.