httpd side: serf to me is the wrong question.
http/2.0 in the simplest implementation is just another protocol to httpd. We have the constructs to handle it, kinda. Improvements to async support in various bits will help. However our constructs about requests and connections (and their pools) are still grounded in the http1 mindset. http2 should challenge us to do real multiplexing of requests. I don't believe our existing hierarchy of pools deals well with the complexities of lifetime management of data in this multiplexed world, especially when you multiply that multiplexed nature of an http2 proxy (or reverse proxy) with its own outbound connections and requests. Additionally there are 'new' things that we don't deal with today, like: * Server Push * Stream Prioritization * Flow Control integration into proxy use cases Things like flow control and stream priorities interact poorly with the output current filter API and model -- calling the next function with a brigade, even if it wants you to try again, every caller has to deal with these complexities of back pressure -- I'd love to have more open discussion about ideas here. http2 will be around for another 20+ years, I'd challenge us to think about it as the default case, and http1 as a fallback case that we still support well, but the architecture and APIs are optimized for the future case. On Tue, Sep 23, 2014 at 12:45 PM, Jim Jagielski <[email protected]> wrote: > APR: > Considering that before we know it, http/2.0 will > be here, and ignoring httpd for the time being, > what features/additions do we see as being needed > to support http/2.0 from an APR library level? How do > we compare w/ libuv, for example? How "event-aware" > should APR be, ala libevent? > > HTTPD: > From the httpd point of view, what does serf > provide for us to help us get to http/2.0? Should > we make it a requirement? Are there things we > need that, instead of making them part of httpd, > should really be in APR instead? What other external > libs should we be leveraging?
