Graham Leggett wrote: > > Mladen Turk wrote: > > > Some rationale: > > > > I spoke with Henri and we decided that although mod_proxy with > > proxy_ajp is a good idea (in the long term... very long > term), we need > > something that will fill in the gaps. > > As there is an existing codebase, getting a module together > that supports Apache v2.0 natively is a good start to clean > up the module and get it aligned with how Apache v2.0 works. >
Yes, that's the general idea. We focus on v2.0 and TCP/IP protocol (for now). > I however will be -1 on the eventual formal inclusion of the > module into httpd natively until it supports the proxy > framework. Well, the development will not be over in 2 days, and the plan is to use mod_ajp as a base for testing new protocol extensions, and to be always a little bit faster and better then mod_proxy with proxy_ajp :). > A significant amount of work has been done in > httpd to ensure that proxy functionality (such as cache) is > available to as wide an audience of users as possible. Adding > a module that neither conforms to the established framework > inside httpd, or offers it's functionality to protocols > outside of AJP I believe is a step backwards for httpd. > The mod_proxy itself will have to face a lot of extra work too. It will at least have to have a maintainable set of connection pools for each backend server, so one can implement a load balancer from them, and also control the number of connections the backend can handle. mod_core will need an extra work too, so that the scoreboard can be extended to store the lb params. This is essential if one wishes to have a load balancer. If you succeed to build such a feature for mod_proxy and http protocol, then we will already have a ready proxy_ajp protocol extension. MT.
smime.p7s
Description: S/MIME cryptographic signature
