Costin Manolache wrote: > > AFICR you said that you will have something to share, and > I'd love to see > > some other, perhaps better ideas. > > No, I'm trying stuff on java side. >
OK. > And just like with code - I don't think we are missing > propositions or > ideas. What is missing is an agreement over what features we > are going > to support ( and more exactly - not support ), as well as a > clear plan > on how to support them without spaghetti. > > I think we do have agreement on droping IIS/iPlanet. We had > agreement on > droping pluggable protocol Apache2, ajp13, TCP/IP With possible dynamic config in stage 2 and ajp14 protocol extension using crypto and compression. That's it. We said that couple of times. > - but that's now back with the > discussion on > mod_proxy ( which also involves pluggable protocol ). > True, the work on that has been initiated, but it has a fundamental difference being included in core httpd distribution. Only that fact is a sufficient reason to forget that 'no plugable protocol' agreement, thought, and of course the fact that the proxy is deeply integrated into the core of httpd, as well as our protocol will consequently. > > Yes, we do have plenty of connectors, and most were written > very fast - > mod_jserv, mod_jk, mod_jk2, mod_webapp, mod_proxy. > > Having a 6th codebase - especially in the context of the growing > agreement over mod_proxy as a long-term solution - is not > what is missing. > Well, the way I see (think that Henri has the similar ideas) is to have the ajp protocol lib, usable to communicate to TC from any container, not only http server, and mod_ajp as a layer on top of it _only_ for Apache 2.0 branch _and_only_ if the proxy_ajp doesn't get back propagated from 2.1 branch. So from the start we know what the final goal is, and what the life cycle of it would be. The code itself (at least the ajp protocol library) will not be a waste, cause we'll use it for both proxy_ajp and any later bizarre usage. To effectively test the new ajp code we need some framework, simple enough and Apache2 centric. We could use the current mod_proxy for that, but it's current design need some changes to be able to support that, and BTW I'm working on that together with Graham, but even he can not say for sure it's going to be in 2.0 branch. There is also a question of development infrastructure, cause we cannot use the httpd-cvs for that, so we'll need to make some compromises, writing few lines of code twice, and hope that somone will apply the patch :). > My concern is that we are just repeating the history of the first 4 > connectors - by writting some initial code that solves the > easy problem > ( sending requests to tomcat ), and hoping the rest can be > added without > getting back to spaghetti. > Well, the only thing you can not beat is the time. It (the time) has a strange side effect to make the things older. I clearly remember a day when I stood speechless in front of a VAX mainframe with 1MB of RAM, wondering who will ever need that and for what. MT.
smime.p7s
Description: S/MIME cryptographic signature
