> > I think we agreed ( Henri had some doubts ) that ajp14 will > consist only > on additional messages, but all the low-level messaging stuff will be > ajp13. > > For that we only need a mechanism to register new message > handlers, and to > have a dispatcher that calls the right handler when a packet > is received. >
that sounds reasonable. > > > so, partly out of sheer necessity, and partly because i > think it would be > > useful, i'm considering doing a major rewrite - no, let's call it > > refactoring :) - of the java code in j-t-c/jk. the goal would be > > correctness, clean up and simplification. i would start > with ajp13, but > > keep in mind there is ajp14, ajp15, etc., to come. i think > i would do this > > on a branch, too, call it ajp_refactoring, or something like that. > > > > what are the thoughts on this? > > +1, I was thinking the same :-) > > I would propose doing it in the main branch, but with a > separate package > name. > > I can roll back my changes in o.a.ajp - and revert it to the 'stable', > and move to a new package ( I was thinking o.a.jk or o.a.jk2 - since > it'll not be specific to ajp, but will also have jni and maybe other). > separate package, main branch makes sense. i like org.apache.jk. depending on the amount of free time i find before the hollidays, you may start seeing checkins there :) > > Right now I'm trying to do some > rewriting/optimizations/apr-istaion on the > C side, I hope to finish most of it next week ( or 2 ). > > ahhh... i remember C code... those were the days ;) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
