merge in to mikeal/request

[mikeal]

we should think about a strategy for merging this in to the main request repository.

there is a good amount of code now that can be shared, the OAuth signing code in particular.

i'd also like new options that people write for node-request to go in to the browser version.

[max-mapper]

aww he likes it!

[jhs]

I would like that too, particulary since browser-request is missing tons of API stuff that request still does.

Off the top of my head, I see a few challenges

1. mikeal/request (at least the README examples) focuses on streams. That is problematic with XHR. Best case, it would bloat the code
2. There is no NPM for the browser. Maybe Ender but I've found it less satisfying than NPM. Do you really want to add a build step and some non-NPM release mechanism?
3. browser-request uses a LGPL library (hence the otherwise unwelcome Git submodule)

[mikeal]

what submodule wants LGPL?

i'm confused as to why we need NPM or Ender? Why can't we just run it through a minifier and release it like everyone else releases their browser libraries?

the docs would change dramatically. we would start with some examples that work in both places, then talk about streams and note that it's node only. then we would list all the options, sectioning them out and noting which sections only pertain to node (you'll never be able to take options like cookiejar).

[jhs]

browser-request builds directly from xhr. However it uses a very nice library called XMLHttpRequest.js (not the best name), like a CSS reset style, but for XHR; it removes all idiosyncrasies and bugs. See http://www.ilinsky.com/articles/XMLHttpRequest/ for a feature list. XMLHttpRequest.js is LGPL.

For that reason, I kept it arm's length via Git submodule.

Good point that we might merge the projects before solving the tedium of documentation and examples. So the following paragraph is not a dealbreaker.

We don't need NPM or Ender; but my point is, for my money, the best thing about Node is NPM. Everything is there. It's simple. Browser libraries OTOH are just total chaos. It's nonstop emails and semi-useful bug reports because people didn't install it right or whatever. Ender and RequireJS solve that; but unless you're Yahoo or Twitter, the medicine is worse than the disease.

So I was reminding you how awful it is to maintain browser libraries, asking if you're cool with that.

[shimaore]

+1

When comparing, say, reqwest or jQuery.ajax, to browser-request, I think the main expectation is that the API will ressemble mikeal/request's, but they don't have to be identical -- it would be fine to have in the documentation comments like "(Node.js only)".

FWIW ahr2 doesn't try to do streams; http-browserify "does".

[rufuspollock]

Just adding a +1 on idea of a possible combination with @mikeal's "upstream" request. Especially see the value of code-sharing and extension with new features.

[shimaore]

Two notes based on things I encountered recently:

• To address the qualms about NPM/Ender, the browser version could be delivered as a component (explicitly: make mikeal/request available as both an npm package and a component). The only existing HTTP request component, apily/request, uses a different (fluent) API.
• JetPack aka mozilla/addon-sdk is another target which could use a mikeal/request compliant API, with a different set of constraints (cookiejar would work, but I don't expect the native stream API to be compatible with Node.js'). The current HTTP request module, request, is based on XHR. The point being that if we're going to make mikeal/request more generic, it might be worth considering what it would take to make it available on that platform as well, so that it adapts to the different platform constraints (cookies/no-cookies, streams/no-streams, http.request/XHR, ...).

[ashnur]

I got here because the request repo I can't use with browserify. This one worked. But now I am confused, You wanted to merge the two almost 3 years ago. That never happened I guess?