Graham Leggett wrote: > Mladen Turk wrote: > > > If I make a design flaw, and the entire project gets > unusable, it will > > make it just something like mod_java, mod_warp, mod_jk and > mod_jk2 are... Dead. > > Nobody will get hanged for that. > > Some code is always better than no code - at best, the code > will be good enough to fit the needs, and will end up in wide > use. At worst, the writers will say "we learned some lessons > from this" and try again. >
True. A week or so before, none of us considered mod_proxy to be a good candidate for ajp protocol. The main reason was presumed 'closeness' of httpd developers to consider something like that. But, fortunately the discussion has led to something that might have a great potential. If we find enough support in httpd developers to accept the needed changes so we can build something usable and powerful enough to fulfill our (and presumably the users) needs, both mod_ajp and similar initiatives will be useless. There is also a question about 2.0 support, and that is the main reason for concerns. If all the changes made to make the mod_proxy 'ajp enabled' gets back propagated to 2.0 then we'll have all that is needed. Other option is to either write something from jk/jk2 in a short period of time (mod_ajp) that will fill in the gap of transition from 2.0 to 2.1, or still hanging around jk and jk2. In second case, I see the mod_ajp as a base for 2.0 users that will ease them to transition to mod_proxy in 2.1. That means that we will try to follow both the design and configuration look and feel the mod_proxy will use. And finally, when 2.1 gets the majority, the mod_ajp will be put in maintaining mode (read; shot to be dead :) MT.
smime.p7s
Description: S/MIME cryptographic signature
