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.
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
Notes
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
Next Meeting