On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez <henri.go...@gmail.com> wrote:
> > If you look at my message, my favourite is *not* a JK3. I'm in favor of > jk > > 1.3. The difference for me is that 1.3 will be very close to 1.2 without > any > > bug architectural changes like migrating to APR. > > ok. > > > I added some examples of new features in my original mesage. You can find > > more examples in our TODO file, e.g. > > > > > http://svn.eu.apache.org/viewvc/tomcat/connectors/trunk/jk/native/TODO.txt?revision=757083 > > Thanks > > > Why not moving into mod_proxy? If httpd were approaching a major version > > change (e.g. httpd 3.0), then there would be the freedom of doing big > > changes to mod_proxy. But httpd is moving towards 2.4. That means the > > architecture of mod_proxy will not change. But mod_proxy as it is today > > doesn't have a clear separation of proxy, balancing and ajp, despite the > > various module names. > > Nope, I suggested moving the actual mod_jk to httpd or may be a pure > APR version of jk (without the #define #ifdef ...) > > > So (and now I am talking about me personally) I think I can still add > > interesting features to a mod_jk 1.3 with not to much effort, whereas the > > barrior of porting existing mod_jk features to mod_proxy before adding > the > > new stuff is pretty high for me alone. > > No problem but you should find more friends to works on it, mod_warp > and jk2 disapears too quickly since they have too few supporters ,) > I agree - there is a big risk that you'll just waste your time if you branch. Even worse - you may risk other people time :-) AFAIK the current trunk is open for features and changes. You can implement most new features with #ifdef or configs protecting the new code, to reduce the risks, and you can do them incrementally. APR is probably the only thing in your list that wouldn't work well incrementally - but I'm not so sure it's worth it. If it really makes your life easier for the new features I guess you can probably just use it for the new code ( with makefile magic ). I agree with Remy that mod_cluster seems to add useful feature - so +1 to add better features in mod_jk :-). Better clustering - in particular better support for multiple apache frontends talking to large number of tomcat backends would be quite interesting. And if this requires a new protocol - I would just pick one of the many existing RPC standards, and maybe move the loadbalancing decisions to a dedicated service. I mean - no need to modify AJP protocol if you need new features :-) Costin
