On 10/25/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > DBUS is a good example in IMO - I'm not
> > saying to use their impl, which doesn't fit, just the protocol spec.
>
> The major power of AJP protocol is known-header-name indexing, and
> IMHO there is no other protocol that is HTTP application focused.

Well, any protocol can do this - with the right message.

In this case: it'll be:
 enum  knownHeadersCode={ .... }
 and the message will have an array of ( knownHeaderCode, string ) and
then ( string string)

Or some other variation - there is nothing so special in Ajp that
can't be encoded in a standard protocol. Except the fact that ajp is
not extensible - so it may save a few bytes.


> If there is really a need for a completely new protocol,
> and I doubt there is a real need for that right now, we must presume
> that the primary intent of the protocol is to allow communication of
> two well known and defined http applications.

Sure - but this can be expressed as well on top of a more standard (
or common ) marshalling. Marshalling is not specific to any
application, not even in ajp ( maybe the stupid 'first chunk' - but
even this can be expressed with few extra bytes in a normal protocol
).

The API you expose - i.e. the message signatures - should remain
specific to the http
app. And a standard protocol would allow you to add all kind of extra
signatures.


> If you look at the XDR protocol, each 'string' type message is prefixed
> with additional two bytes compared with AJP, so beside that, the lack of
> header indexing would at least double the packet size, and downgrade the
> performance by twice.

I don't think the 2 extra bytes is such a big problem.

Actually there is one thing that is unique to AJP - the callbacks done
over the same connection, as responses ( since tomcat can't initiate a
call ). But even this can be expressed in a proper RPC - by having the
callback as a normal response.

Costin

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

Reply via email to