2-argument callback instead of 3-argument

[solatis]

Hi there,

Something that noticed was the callback that adds a third argument which is a shortcut to response.body. The node.js community has pretty much settled on the 2-argument callback, which in turn caused a whole ecosystem of utilities that make this assumption (eg node-async and Q).

What is the rationale behind this? And would you mind it if I made a patch that detects the arity of the callback and behave in a standard-compliant way again if the caller requests so?

BTW I must be overwhelming you a bit with all these requests but I think there really is a place in the node ecosystem for this library, since it is one of the few libraries that actually is pleasant to use. :)

[tomas]

Haha, not overwhelmed in the least. Always happy to work with a motivated and talented coder.

Initially, needle didn't set the body as resp.body, so the only way to get the body was by using the third argument. Then I started storing the contents in resp.body an simply linking the third argument to that variable, and updated (some?) of the examples in the README to reflect this.

I'm not so sure, though, about the community "having settled" on the 2-argument callback, because of the uncountable and different scenarios for each and every app or library out there. I was actually thinking of having a way to retrieve the original, raw response besides the parsed/decoded one, although haven't really wrapped my mind around this.

Anyway, does it really hurt to have a third argument? Are there any libraries that complain about this? If so, sure, let's implement some kind of detection -- just remember to keep it lean! :)

[solatis]

See my line comment in the pull request -- it illustrates the problem a bit.

As far as I'm aware, people call this

asyncFunction(function cb(err, obj) { ... });

Node.JS callback style. It's the style used in the core libraries and style generally approved of -- consider for example the visionmedia/node-thunkify library which converts "regular node functions into a function which returns a thunk", s "regular node function" being one which accepts a two-argument callback.

Having said that, I have to admit I'm really really new to Node.JS, so I could be mistaken. But generally this is an area where I know what I'm doing. :) The patch will be a few lines at most, but I feel pretty strongly about that a library such as this should behave in a standards-compliant way. Doing this correctly opens up the possibility to integrate with all kinds of libraries. I'm probably going to code a few more examples tomorrow that illustrate the flexibility this brings.

[solatis]

Also, i will look into returning the raw streams. Now that we've refactored that part, all we need to do is come up with an elegant way to provide access to the 'pipeline' variable. I'll see if I can come up with something that doesn't introduce any dependencies -- but with an optional dependency, I think there are elegant ways to do this!

[tomas]

Sure, go ahead. I guess something like resp.original_body or resp.raw_body would work (assuming callback mode).

I'll take a second look and merge your PR in a while.

[solatis]

Nah I have something better in mind, giving access to all streams in the
pipeline without additional function calls (but staying compatible with the
current interface).

I'll come up with something tomorrow.

On Tuesday, March 25, 2014, Tomás Pollak notifications@github.com wrote:

Sure, go ahead. I guess something like resp.original_body or resp.raw_body
would work (assuming callback mode).

I'll take a second look and merge your PR in a while.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/53#issuecomment-38627400
.

Sent from my iPhone

[solatis]

By the way, with regards to the "original_body", it is going to look like this:

var rawStream = needle.get(...).raw ();

Notice the .raw() behind it -- elegant way to provide access. You can get access to the whole pipeline like this:

var pipeline = needle.get(...).pipeline()

But I'm not sure about that last one, might be a bit too much feature-creep.