On 08 Oct 2015, at 1:45 PM, Jim Jagielski <[email protected]> wrote: > Yeah... it was 'always' foreseen that mod_h2/mod_http2 would provide > useful clues on how to make 2.6/3.0 better, especially w/ the idea of > slave connections; basically, as you say, let the MPM make mod_http2's > job easier by abstracting out a lot of the tricks that mod_http2 needs > to do to something that the MPMs themselves provide. > > At that same time, however, was/is the need/desire to support http/2 > in 2.4.x (in fact, mod_h2 was *designed* w/ 2.4 in mind). So we are > in this initial stage where what's in trunk isn't perfect for trunk > (http/2-wise) but that's because it's really architectured for 2.4. > > Once 2.4.17 is out, then I expect mod_http2 to start diverging between > the trunk and 2.4 variants, as the version in trunk drives the MPM > designs there, which correspondingly drives mod_http2 in trunk as well > (ala a feedback loop). My goal was/is to make motorz "ideally" suited to > support http2.
I don’t yet see a big necessity for diverging. So far the changes required have all been backportable to the v2.4 series, and I believe we should continue to strive to do so until we find we really can’t. I am sensitive to our release cycles - on purpose, we don’t release minor releases often, and that is a good thing. We want to ship something that is stable that people can deploy and forget about, rather than something that changes out from underneath you every six months. I don’t want to wait till v2.6 to get async behaviour, and I don’t believe we have to. :) Regards, Graham —
