> BTW, we'll need to discuss about the Java side - so
> optimizations on the "lower" level would work on any container.
>
> At minimum we need MessageBytes or equivalent, MimeHeaders or equivalent
> ( i.e. recyclable, low overhead, etc ), and a simple Request object that
> can be easily adapted to TC3.3 and TC4.0.
>
> This is not the "easiest" solution - from my point of view the easisest
> would be to just write the Ajp14Interceptor and use the existing and
> optimized 3.3 infrastructure. ( and use a reimplementation of the protocol
> for 4.0 - using their low-level objects ).
>
i'm not 100% sure i understand what you're saying, but i'm pretty sure
you're talking about something i've been thinking about :)
in tc 3.x, the ajp stuff uses core tomcat classes like MessageBytes,
OutputBuffer, Request, etc.. for my ajp13 implementation for tc 4, i
removed refs to tc 3 classes, and used tc 4 classes where i could (i.e.
HttpRequestBase).
i was thinking that versions of MessageBytes, OutputBuffer, Request (and
Response??), and other classes might find their way into
jakarta-tomcat-connector, so they could be used with ajp code across
different versions of different servlet containers.
are you thinking this would be the right thing to do? seems like you
might be suggesting multiple ajp13 implementations for multiple servlet
containers.
i think it would be better to have the core ajp13 code separate from
servlet connector/adapter code. that way, hopefully, you could use the
same ajp13 core with connectors for tc 3, tc 4, jetty, and so on.
thoughts?
