>> The problem is not only the Request object, but the whole
>infrastructure
>> needed for efficient communication ( MessageBytes, Headers, etc ).
>>
>
>i've started down this path (1). there's a bunch of stuff in tomcat 3
>(like MessageBytes) that would be useful... i posted a
>message a couple
>days ago about putting these kinds of things in a common place, but got
>no response. so, i started using a way scaled down version of my own
>MessageBytes as a placeholder.
I asked for that one or two weeks ago , at the time I asked
for jakarta-tomcat-connector). I asked then for a jakarta-tomcat-commons
sub-project, but there was no usefull answer (only flams and polemics).
We asked also last week for a new CVS, jakarta-tomcat-realms but there is
still no answers ?
>> In both cases you'll need an adapter - if the connector defines an
>> interface with set methods, you still need a
>container-specific object
>> that implements that interface.
>>
>> If you use concrete objects - you'll need a
>container-specific adapter,
>> that implements container-specific interfaces on top of the connector
>> objects.
>>
>> In both cases you need an adapter - but in the first case
>you have much
>> more "power" and flexibility in doing "smart" optimizations
>( like delay
>> the send of the headers or pre-processing more on the server side ).
>>
>> The connector must deal with the communication between servlet
>> container and web server - and it must hide some of the
>complexity ( like
>> how buffers are managed ).
>>
>> Costin
>>
>> >
>> > presumably, any container in which the ajp connector is
>being used will
>> > already have some request object with a bunch of set
>methods, so the
>> > interface approach is probably less work. however, the
>concrete object
>> > approach is probably more efficient, as it's probably
>easier to delay
>> > conversion from bytes to strings in this case.
>>
>> >
>> > anyway, i'm not really sure what the best approach is --
>that's why it's
>> > a dilemma :) -- so, i'm looking for opinions, suggestions,
>etc. here.
>
