tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: jakarta-tomcat-connectors documentation/summaries
Date Mon, 29 Apr 2002 16:10:36 GMT
On Mon, 29 Apr 2002, Christopher K.  St.  John wrote:

>  Ok, I'm maybe being thick here, but I want to make sure I've got this
> straight. The idea is that anyone who's clueful enough to search the
> archives is likely to come across the term "AJP14", so it's best to 
> give them a hint (even if term isn't going to mean anything to somebody
> who just wants to evaluate the current set of connectors)
>  So, to confirm:
>  AJP13 defines marshalling protocols. It also has
> a command set that uses those marshalling protocols. AJP14 uses the
> same marshalling protocol as AJP13, but extends the command set.
> The distinction is important, because in the past major version
> number changes in AJP meant an entirely new binary protocol.
>  AJP14 is for the future, sometime after the release of jk2. It's
> still being discussed.

No. AJP14 was an experiment to extend AJP13 - but we agreed that 
keeping Ajp13 stable and frozen and stable ( and remaining compatible
with the whole range of tomcats ) is better than whatever improvements
we could gain.

And I strongly believe that in the future we'll either stick with
ajp13, or implement a subset of XDR or CDR - i.e. a standard 
marshalling ( and an even smaller subset of the rpc semantics ).

To avoid confusion, we should stop discussing about Ajp14 - and 
stop using the same term for protocol and API. 

There is one wire ( binary ) protocol, ajp13.  

PROPOSAL: let's use 'jk1 API' to refer to the set of methods/callbacks
used in jk1 - that's the base API that is supported in all tomcat
versions ( starting with 3.2 ). 

The only reference to ajp14 should point that there is no ajp14.
Ajp13 was designed from start as a RPC-like protocol ( with minimal
overhead, etc ), and we don't have any use case where ajp13 wouldn't

The only limitation is that it support only 255 methods ( unless
we use an expansion ), since it has a byte as method code ( to 
facilitate table-based dispatching ). 


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message