> Now the only performance issue on my list is mod_jk ( the java side still
> need work to improve a bit the performance ). But fixing the bugs and
> making tomcat easier to use is far more important - and the connector
> module can be released independently, as a standalone module ( i.e. after
> 3.3 is released - stability is also more important than performance,
> I would vote for an ajp14 for performance and other "dev" enhancements,
> and making ajp13 the "stable" protocol instead of 12 ).

+1.

We're still shaking weird little bugs out of the ajp13 implementation(s),
and people are relying on it for production use.  I don't think we should
muck around with the protocol itself.

When ajp14 is developed, the spec should really contain a standard response
for an "unknown packet", so new packet types (or messages) can be added to
the protocol without breaking backward compatability.  If we had this in
ajp13, we could add some very nice things as negotiated features (e.g.
encrypted and/or authenticated connections).  However, because ajp13 has no
way to respond to an unknown packet, the implementations generally behaves
very badly if you send them something they're not expecting.

-Dan
 
-- 

Dan Milstein // [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to