[Meeting] 2015-10-22 - Minutes

[jasnell]

HTTP WG Meeting - 2015-10-22

Attendees

James M Snell (@jasnell)
Jeremiah Senkpiel (@Fishrock123)
Brian White (@mscdex)
Patrick Mueller
Eran Hammer
Doug Wilson
Myles Borins

Agenda

• What the heck are we doing here? (level-set on purpose of the WG)
• Establish WG Scope, Work Items, Focus for Charter
• Start to identify current HTTP module pain points
  • for core
  • for modules / ecosystem
• Identify non-goals

Notes

• Current open HTTP related issues: https://github.com/nodejs/node/issues?q=is%3Aopen+label%3Ahttp+is%3Aissue
• Current open HTTP pull requests: https://github.com/nodejs/node/pulls?q=is%3Aopen+label%3Ahttp+is%3Apr
• (old repo issues: https://github.com/nodejs/node-v0.x-archive/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Ahttp)
• (old repo PRs: https://github.com/nodejs/node-v0.x-archive/pulls?q=is%3Aopen+label%3Ahttp+is%3Apr )

Minutes

James: So the purpose is to take a look at the http core module and see where we can advance and evolve it in context of core and the module ecosystem

Brian: no other thoughts

Eran: Main goal is to boost the http support that is provided, externally as much as possible.

Jeremiah: Come to a decision of what core should provide… just a low level or everything for the spec, etc

Patrick: Pretty much just lurking… looking for places to contribute back.

James: Discussed how core WGs work under the foundation

James: Need to capture either long term changes, or keeping the existing http module in the charter

James: node currently doesn’t implement the entire http spec, and there has been some discussion whether it has to be or not

Patrick: should probably support the existing version for a long while, compares to python / etc. Perhaps prototype a whole new module.

Jeremiah: if we need to take the http module out or making a new module, do we need to take tls out too?

Brian: Could we solve a majority of the pain points by making the http parser easily swappable at runtime?

James: maybe Doug and Eran can outline some pain points?

Eran: first step should be to break it into a stack we can reason about and tell where those parts should go. We should write these parts stand-alone even if they are in core. TLS shouldn’t be required, but we will have to co-ordinate with it.

Doug: Also agree TLS is unrelated. What Eran said makes sense.

James: [lists some parts] what would an underlying module need to provide to implement these

Patrick: We should collect these as use-cases, and then think broader

James: we should get use-cases so we can get a charter

Partick: We shouldn’t rush this to get a charter, not at the state we can make claims about what we will do concretely

James: What would be a success criteria for this WG? What does this WG need to accomplish to be worth the time?

Doug: The http server isn’t very low-level and more like a framework compared to the built-in http client. We should come up with a plan of how to take about the http server to take it apart into the low-level framework and actual http mechanism.

Patrick: Might be a good idea to split concerns for http in terms of client / server. Always end up in the http docs, and it’s a bit confusing to have the client and server together.

Eran: Is anyone working actively right now to move the parser to JavaScript?

Brian: I haven't had time to work on my implementation since July. Fedor has done some work in C/C++ land to do a lot of perf in the current parser. My parser works very closely to how the C/C++ parser does. Was made to be drop-in for the current http parser.

Eran: When I was writing the injection code for Hapi it was pretty painful, the current parser exposes some stuff but it’s pretty confusing.

Doug: Same issue as Eran.

Patrick: We should also improve the test-cases.

Doug: Docs aren’t so lacking, but the public interfaces just aren’t really enough.

James: [Lists some consistent themes of this discussion]

James: I propose we start filling these details and pain points into the HTTP WG issue tracker.

James: How do we want to go forward? Bi-weekly call / regular meetings?

Patrick: Some context from the tracing WG on meetings, the goal there was originally monthly.

James: We should probably have some pressure since this is pretty important for core and user-land.

Actions

• Document current pain points in the existing HTTP module in core
• Having HTTP WG review PR’s that affect the HTTP module in core
• Documenting use cases for separating out low-level mechanism vs high level framework
• Identify potential improvements to better support userland ecosystem
• Improving the documentation around the HTTP bits
• Improving documentation for the http_parser that’s currently in core, improving test cases, and formalizing the API
• Meeting again in 2 weeks. Until then, beginning documenting as much as possible in GH issues.

Next Meeting

• 2015-11-05 @ 1pm Pacific Time