Graham Leggett wrote: > > Thing is it's easier for end users to not have to mess around > with third party builds if it can possibly be avoided, and > it's the needs of the end users who are the most important, > not the developers. >
It was the main reason why we tried to go beyond the concepts of jk/jk2 and co. Also, nowadays almost every server implementation requires some sort of dynamic context delivery. Ajp concept has a nice feature not being dependant on any external toolkits like for example mod_perl and php are, so it's a good candidate for inclusion inside the core distribution. > The fact that the current module has to be built separately > is a huge issue for the users of the module, making such a > module a built in addition to proxy will make people's lives easier. > Henri tried to see if there is a common interest to possibly make a mod_ajp part of the core distribution. Think that discussion is leading to use the mod_proxy like a container for ajp protocol, that could be fine, but something like mod_proxy concept we already have in the jk2, called modular protocol. The main reason why we are trying to make a successor for jk/jk2 is simplicity and static set of requirements. Trying again to use the something would lead to the same problems thought. I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I think it would be better that we develop the module inside j-t-c tree, and kindly ask the guys to see if there is a possibility to include it in the core distribution, when we reach some level of stability. MT.
smime.p7s
Description: S/MIME cryptographic signature
