On Sat, Apr 4, 2009 at 8:12 AM, Mladen Turk <mt...@apache.org> wrote:
> Costin Manolache wrote: > >> So in essence you have a new protocol but the sole >>> difference is how you describe it. >>> >>> >> >> The API can be something like: >> - legacyRequest(RequestMessage) - whatever we have in the current AJP >> protocol >> - getServerLoad() and whatever new we wanted to add >> >> Instead of defining AJP extensions, we just pick one of the marshalling >> libs >> and use them >> for encoding the new methods. >> >> > Again, you are presuming a new protocol and IMO everyone > here are just getting nasty red spots on their faces when > you do such a thing ;) > My understanding was that some people want to add features to mod_jk to support extended load balancing, eventually the fancy async stuff, etc. I can't see how this can be done without proto changes - current AJP won't work. And this is quite specific to tomcat, you can't dump it on incubator. What I'm trying to suggest is that a 'new protocol' ( as in - enhanced AJP, AJP2.0, etc ) is not a good idea. Instead the extensions needed should be done by using existing libraries and protocols, and when this is stable the AJP protocol should be deprecated (thus reducing the code size). Thrift/protobufs can be used quite easily on top of an existing transport, as payload, and can represent all the messages you want. Costin
