On 25 Sep 2014, at 2:13 PM, Paul Querna <p...@querna.org> wrote: > 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.
A while back I built two async-only applications backed with APR’s pools that handled a similar problem as to the one described above, and the APR pools were not only highly suited to task but were also key in making sure it all worked properly. In the first case we used libev, and in the second case we used libevent. Ideally I want to be able to use APR without having to prop it up with an external event library. If we can enrich the apr_poll library to the point where it gives us the full range of event functionality that will be ideal. > 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. Dealing with back pressure is the reality - the idea that you can blindly pass an arbitrarily large body of work to a downstream filter and not give that downstream filter the option to say “woah there, slow down” is where we suffered. I believe the API I proposed handles this, so far it works pretty well. > 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. I think it all begins with apr_poll (or it’s successor). Regards, Graham —
