> On Fri, 5 Apr 2002, Remy Maucherat wrote:
>
> > > There is no problem if we use 2 Http11Protocol, one with ThreadPool
the
> > > other with 4.0 threads. Right now I'm working on the TP one.
> >
> > We don't need two, so I'll try yours ;-)
> > Do you plan to write the Http11ProtocolHandler ?
>
> A
On Fri, 5 Apr 2002, Remy Maucherat wrote:
> > There is no problem if we use 2 Http11Protocol, one with ThreadPool the
> > other with 4.0 threads. Right now I'm working on the TP one.
>
> We don't need two, so I'll try yours ;-)
> Do you plan to write the Http11ProtocolHandler ?
Already done, bu
> On Fri, 5 Apr 2002, Remy Maucherat wrote:
>
> > > It's easy to implement it in http11 - this is duplicated in the 33/40
> > > versions. I would prefer to use the 33 thread pool from util, but
> > > I'm ok with the code used in 40 ( or I can implement both, with an
> > > option ).
> >
> > The 4.0
> Hi,
>
> In order to merge the connector-related code in Coyote and jk, I need
> a different abstraction. Processor takes InputStream/OutputStream params,
> and assumes the connector will listen on the port, etc.
>
> The problem is that it doesn't map to things like JNI and is hard to
> abstract
y well tested and optimized. I can add the threading code
from 4.0, it's not hard - but then we'll have to plug PureTLS and
many other things that are only implemented in 3.3.
Costin
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTE
fairly cheaply.
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 04, 2002 3:25 PM
Subject: Coyote: replacing Processor with ProtocolHandler
> Hi,
>
> In order to merge the connector-related code in Coyote and jk, I need
&
Hi,
In order to merge the connector-related code in Coyote and jk, I need
a different abstraction. Processor takes InputStream/OutputStream params,
and assumes the connector will listen on the port, etc.
The problem is that it doesn't map to things like JNI and is hard to
abstract things like
