Costin Manolache wrote:
and certainly not
worth creating a new protocol. We need to pick one of
thrift/protobuf/hessian for
marshaling, and start doing some mux-ing in the protocol.
All those framework you mention are just helpers for
*building* the custom protocol. They actually mandate
that we will have one but now hidden inside some IDL
language description. Any such framework makes
almost impossible to change the protocol specification
while preserving backward compatibility
(One huge problem why AJP is not usable any more)
You preserve backward compat by keeping the protocol stable
and supporting all methods you define in the IDL. What is needed
is bi-directional communication between web server and tomcat -
so you can do all the extensions on the list.
The stability of the actual method definition is probably more important
than the protocol itself - if we start using an IDL, it is even possible to
expose the methods over multiple protocols if there is a
compelling reason.
Sure, but then you force everyone that wish to talk to you
to use the same framework. The same thing can be done
with a pencil and a peace of paper cause we only need one
protocol, not zillion of them.
So in essence you have a new protocol but the sole
difference is how you describe it.
None of them has multiplexing (Google protobufs doesn't even
have the transport layer just marshal/unmarshal, while thrift
transport is unix only).
The only OSS solution that I know is w3c's http mux, but that's only
Java part and IMO incompatible with ASL license.
I'm kind of more fun of
http://www.wsgi.org/wsgi/
At least it's human readable and already working :)
Well, the spec is not so human readable :-) - can you point me to the
description
of the communication protocol - i.e. the marshaling, framing, etc ? I don't
mind
'human readable', or even supporting multiple formats. Are they multiplexing
or
request-waiting-response ? Do they already define methods for load
balancing, etc ?
If yes - sure, it's one valid option.
Sorry, Costin I was pulling your leg with that.
It's an example of where we could end up eventually.
In essence there is no webserver/backend (proxy) protocol
or standard that exists and that is usable with
async, security, rpc and multiplexing support. Period.
The only dedicated one were AJP and FCGI, but both
were designed with web.0 in mind.
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
