William A. Rowe, Jr. wrote: > At 04:48 PM 5/2/2005, Paul Querna wrote: > > >>Personally, I have held off on starting refactors of code, because I do >>not want to be detrimental to the ability to make a 2.2 Branch. >> >>I would like to investigate making more parts of httpd async, in >>conjunction with the Event MPM. I would also like to redo some of the >>configuration system -- but I have avoided working on these, because of >>my personal belief that 2.1-dev has enough for a new GA branch. > > > First - let me say I TOTALLY agree with your concept for more > async features and design!!! > > Second - there is no way that disconnected/async events that can > jump threads will ever fit into httpd-2. That quantum leap must > be httpd-3 because it breaks the assumptions and gross hacks of > many module authors. Even if we 1. never leap threads between > translate_name and finalize_request, therefore 2. restrict all > async to the reception of the request packet; there will still be > affected modules, mod_sspi and user tracking apps that span > pipelines - which don't expect data to jump threads on the connection > layer. > > >>I think there is wide agreement that /trunk/ should always be open for >>commits. I don't imagine that my personal development ideas match >>everyone, and they are not my only reason for wanting a 2.1.x branch. > > > Absolute rule, trunk/ should always build as well. If it can't build, > it should be reparable within a very short window. Hopefully not by > the committer, but more likely, by platform maintainers 'catching up'. > > That said, I'm strongly -1 on dropping such radical changes directly > into trunk/. There is no way code changes on this scale are ever CTR. > We have SVN, so creating sandboxes/experimental/proof-of-concept > branches are trivial :) > > This was true of every major refactoring of Apache since Shambala. > Create a sandbox today to start experimenting with async models.
I agree, a sandbox would be good for these types of changes, but I haven't even started a sandbox, because I do not want to try to land it back into the current trunk of 2.1-dev. The types of things that making it more async could change would significantly change the compatibility with existing modules -- and like you hint at, could imply a 3.0 type change. I didn't mean to paint my disinterest in doing this work now as not making sandboxes or working directly in trunk, but, mostly that I don't think merging them back into trunk is reasonable, if we expect 2.2 to come out any time soon.
