Re: emit('data') best practice

[tjholowaychuk]

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.

[Mike Nichols]

Thanks for your response.

I guess my question is whether to emit a 'data' event when there isn't any "raw data", but the underlying reply from redis is considered to be an 'empty list'. The zen semantic in me asks 'is the absence of data....data' . :) 

But seriously, it just feels like a subscriber would always want to know that 'empty', not nil, was the reply. 

[Jake Verbaten]

A way to solve this is open an issue on the repository. You'll get one concrete answer.

--
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

[Mikeal Rogers]

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

[Dominic Tarr]

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.

[Mike Nichols]

Thanks for the feedback. 

Just a note, this isn't dealing with pubsub in Redis but rather how it replies to multi-bulk commands...commands which will receive more than one item.

The problem with dropping this empty reply is the necessity now to bind a 'end' event and check if data- a reply - was returned.