I was thinking more as - pick a 3rd party RPC/marshalling - like thrift, protobufs, etc, use it for all the new cluster/etc communication - and later for HTTP forwarding too (instead of extending AJP )
- add all the new features as separate source files, with minimal #ifdef-controlled glue. If they happen to depend on APR or something else - it's ok. - keep releasing out of the same branch - i.e. making sure nothing that works is broken but people can use the new features without pain. - when all the new features are implemented and we have a replacement protocol that has been around ( optional ) for a while - drop the old code and branch 1.3. Costin On Tue, Mar 24, 2009 at 1:07 PM, Henri Gomez <henri.go...@gmail.com> wrote: > The library approach could be a good way to help people/corps use AJP. > > And it will force us to split better between AJP code/functionnality > and WebServer operation (it's not really the case today). > > This AJP library could be fully APR (and so remove the pain with > #define / #ifdef...) > > > 2009/3/24 Costin Manolache <cos...@gmail.com>: > > On Tue, Mar 24, 2009 at 8:46 AM, Rainer Jung <rainer.j...@kippdata.de > >wrote: > > > >> On 24.03.2009 16:29, Costin Manolache wrote: > >> > >>> On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez<henri.go...@gmail.com> > >>> wrote: > >>> > >>>> 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 :-) > >>> > >> > >> But if we do not branch, then we need to go on doing all changes on the > >> production branch. trunk is identical to 1.2 and is the only code line > we do > >> use at the moment. > >> > >> The proposal says we branch of trunk to 1.2 and keep that stable. There > are > >> people around here who do not like the idea of having many more 1.2.x > >> releses of JK, because each new feature brings a risk of breaking the > >> existing code, that is pretty stable. > > > > > > > >> > >> Separate trunk and 1.2 branches would give us a chance of going a > slightly > >> higher risk in 1.3. Another important thing: in Jk 1.2 we follow the > policy > >> to mostly not change the default behaviour between the 1.2.x releases. > But > >> most important timeouts were created late in the release cycle, so all > of > >> them are of by default and as a user you need to do a pretty lengthy > >> configuration for getting a good usage experience. With 1.3 we could > improve > >> our defaults a lot. > > > > > > I think the mistake with jk2/webapp/etc was the same - assuming we can do > > major destabilizing work ( including changes to configs, etc ) > > and at some point people will just migrate - while at the same time > > maintaining the 'stable' code. Which of course everyone sticks to. > > > > I see no reason why you can't add features to trunk. If people want to be > > sure it is stable - they should review and test the changes > > and make sure the new features are modular enough and don't change > existing > > behavior. We have labels for each release, and if > > a major bug happens we can branch and release an emergency 1.2.x.y fix. > But > > we shouldn't say '1.2 branch is for stable work, 1.3 for > > new features/risks'. All new features go to trunk, the trunk should be > > mostly stable at all points - and have releases after a number of > features > > get added to avoid 'big change' problems. > > > > Timeouts and features should be set in the config - you can just ship a > > 'backward compat config' and 'new config'. > > > > > > > >> > >> > >> 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. > >>> > >> > >> The discussion is exactly about "how open for changes should trunk=1.2 > >> stay, now that JK is pretty useful and feature rich". Many #ifdefs are a > >> nightmare and using config means everything will stay off by default. > One of > >> the major problems we now have (with 28 released versions of history). > > > > > > Well, trunk and 1.2 are just names. Trunk means 'active development goes > > there', 1.2 is the major version and means 'we'll keep it backward > > compatible until we change the label to 1.3'. > > > > For many of the features in your list you don't need ifdefs, just new > files > > and config options - and I don't see anything wrong with > > having the options off in the default config file. Just add a new config > > with all the options 'on' :-) > > > > > > > > > >> > >> 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 actually do want to proceed working incrementally in the future > trunk=1.3 > >> too. Exactly because there is a big risk of not enough commitment for a > big > >> lengthy change like the APR migration. > > > > > > Than just leave '1.3' out, and work on the other features in trunk. > > > > I see no problem of mod_jk having an optional dependency on APR for the > new > > code, or having an optional > > dependency on some RPC library with compatible licence. ( using an > external > > library would also avoid the > > problem of nobody having time to implement a new ajp protocol ). > > > > Costin > > > > > >> > >> 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 :-) > >>> > >> > >> I totally agree about the usefulness of this. I would love if someone > would > >> chime in and work on that. > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
