it's much easier to write high level apis with js objects in streams, and then pipe to a stream that can stringify it. This reduces glue code, and increases flexibility, because you can use a high level stream with any kind of text-stream.
Otherwise every stream module needs a parser... or you get more monolithic tools that wrap tcp servers or socket.io. In this case, prehaps the best thing is to emit a data event with an empty array in it. the pub-sub feature of redis is a bit weird, kinda tacked on to redis, but probably better to let it's own documented behaviour 'fall through' rather than try to 'fix' it. On Tue, Sep 4, 2012 at 5:15 PM, Mikeal Rogers <mikeal.rog...@gmail.com> wrote: > I tend to agree. > > The current implementation in most of node allows setEncoding to change the > data event to emit buffers. In the case of several userland streams strings > are emitted. > > For efficiency, if people are expected to work with the data as a string it > is much cheaper to avoid unnecessary conversions, but IMO it's painful to > not be able to assume "data" events will be Buffers. > > -Mikeal > > On Sep 3, 2012, at September 3, 20128:26 PM, tjholowaychuk > <tjholoway...@gmail.com> wrote: > > IMO if the idea behind streams are to act like pipes then "data" events > should only be "raw" data aka Buffers (strings too I guess), > if it's a non-stream then whatever I guess > > On Monday, 3 September 2012 15:44:55 UTC-7, Mike Nichols wrote: >> >> When issuing a redis command which expects a multi-bulk reply but the key >> does not exist, one may receive the following: >> +OK >> *0 >> >> The redis docs say "If the specified key does not exist, the key is >> considered to hold an empty list and the value 0 is sent as multi bulk >> count." >> >> It seems like it is proper to emit a 'data' event in a client library with >> the 'empty list' redis implies so that consuming code can use it in a >> pipeline and let the consumer handle the `empty list` there. >> >> This came from looking at 'https://github.com/tblobaum/redis-stream' where >> this sort of reply drops the data, thus breaking the pipeline. >> >> This leads me to the greater question on whether or not to emit 'data' for >> a empty value. My gut says low level libs like these _should_ emit the event >> with empty data but I wonder what other authors are preferring. >> >> Any opinions would be appreciated on this. >> > > -- > 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 > > > -- > 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 -- 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
