Repository navigation
WG: Considering a new HTTP WG #3214
Description
Activity
If so we should also pull in someone from Hapi. @hueniverse any recommendations?
+1
I'd participate, for sure.
I'll participate at first to see what it will look like.
@hueniverse .. at this point, what it will look like will depend on the priorities of those who are involved as well as the needs of the community. So given that, I would turn the question around and ask you: from your point of view and from Hapi's point of view... what (if anything) should be the top priorities for a WG looking at supporting / evolving the http support in Node core?
I mean... I have a number of specific things that I'd like to see happen, but, to be honest, it needs to be driven to a large degree by what the community actually needs, which is why having both Hapi and Express represented in the WG is ideal
Let's get an initial call spun up to discuss: http://doodle.com/poll/8hy262fu5xn4kp8a
I would like HTTP to move out of core into a separate set of npm modules. That would be my ideal setup.
@hueniverse Why do you want it out of the core?
@pmq20 I want everything out of core :-)
I think we are hurting the community by not allowing some healthy competition in offering better or different approaches to HTTP. It is impossible to get anyone to care about it when it comes with core and using something else feels like an exception.
I would like to see an HTTP implementation that goes further in terms of handling headers, status codes, etc. Right now, every framework has to deal with a lot of these things on its own over and over again.
It would be great to offer a few high quality modules like an HTTP parser and TLS constructs that people can use to write their own. For example, I wrote a module called shot which simulates an HTTP request against a live server to avoid making a network call. I would like to be able to implement it without feeling dirty about the hacks I had to do to get it working.
+1
It is impossible to get anyone to care about it when it comes with core
Maybe during the two-year limbo, but not anymore. :)
@pmq20 I want everything out of core :-)
Also I'd like to just leave a note about "what belongs in core" from the perspective of core:
If it cannot be done outside of core, at all, or without great pain, it probably belongs in core. Also, anything that currently exists in core belongs in core unless it was effectively private.
That is:
- If people can't do it outside and people need it, it belongs in core. Similarly goes for something that is very painful to do outside of core. Stuff in this category is basically core's job.
- If it currently exists in core, it (probably) belongs in core. I.e. we can't break the ecosystem. Our deprecations have to have time on the order of a year or so, at minimum, for even small features.
- Given that http is used by a huge percent of the ecosystem, we can't remove it without a multi-year timeframe. This is probably something like a hundred of thousand modules, or will be soon. Directly or indirectly.
- Things that can be removed fall into one category: use of them is almost not impactful. I.e. tops 100 (small) modules use it. If things are private, we may expedite this. See deprecate
_linklistfor an example. - Security issues may bypass all of the above, if necessary.
Again, I'm just try to lay out some prior groundwork here so that everyone's expectations can be reasonably based. :)
I think we are hurting the community by not allowing some healthy competition in offering better or different approaches to HTTP
Can you be a little more specific. Hapi.js has an API that is quite different from core and has built a rather successful ecosystem around it. What were you not able to do, or would have done differently, if you weren't building on top of the core HTTP API?
14 remaining items
Canceled the hangout. Only @dougwilson and I showed. Will reset and schedule a new hangout and hopefully get more there.
Probably better to send an actual invite... eran@hammer.io
Doh, forgot that was today. :/
Hi folks! I would love to be involved. I've been talking to @Fishrock123
Since the hangout was cancelled, is there a new doodle for the next one? I had forgotten about the first hangout.
I'll be setting one up shortly
On Oct 14, 2015 1:34 PM, "Brian White" notifications@github.com wrote:Since the hangout was cancelled, is there a new doodle for the next one? I
had forgotten about the first hangout.—
Reply to this email directly or view it on GitHub
#3214 (comment).Fwiw: I'd also like to join. (I worked on express prior to Node core)
@jasnell ...I guess I'm late to the party. @mhdawson mentioned that I should be a part of this.
@mikeal @hueniverse this discussion is eerily familiar. IIRC this goes back to some agreements at the first node summer camp:
- innovate outside of core
- do as much as possible in JS (instead of C++)
I agree whole heartedly with both ideas (then and now). Especially with this:
... move HTTP out of core into a separate set of npm modules.
This would allow the community to innovate around
http. That might mean different things to different people: but I think thats the point.The reality is, its going to be a fairly difficult process (its not just a matter of hacking the modules together, we need good documentation, need to educate people/frameworks to use it instead of core, etc), and people that normally don't work together are going to need to.
If you guys think it makes sense for me to be involved, I'd be glad to help. But I've noticed these working groups get pretty large pretty quickly, and that doesn't sound so practical IMO.
@ritch ... doodle poll for scheduling here: http://doodle.com/poll/xbqfpqv7hfcriwin#table
fwiw I've filled in the doodle, my availability is a bit spotty next week cause of travel and beyond that will be awkward because of timezones. While I'd like to be involved I don't want to be a blocker to getting new folks involved so count me out if it doesn't work.
all the meetings are after midnight for me, but i will try my best to attend the first ones.
FYI: Meeting is scheduled for Thursday, Oct 22 at 1:00pm pacific time.
keeping this on
tsc-agendacause a quick report from the initial meeting might be helpful
I am considering the formation of a new working group to take responsibility for the HTTP and HTTPS submodule in the core lib. The HTTP WG would take responsibility for the http API, the http-parser depenency, implementation of HTTP within core, as well as support of HTTP in the larger ecosystem.
I am opening this issue to solicit input on (a) whether such a WG would be considered helpful and (b) put out a call for participation.
/cc @nodejs/tsc @indutny @dougwilson @piscisaureus @mscdex