httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: [PROPOSAL] Branch 2.1.x on May 13
Date Tue, 03 May 2005 08:19:26 GMT
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.


Mime
View raw message