On Sat, Apr 4, 2009 at 1:10 AM, Mladen Turk <mt...@apache.org> wrote:
> 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 think it is good to separate marshaling from the transport and the actual service API. Our main value is the API - simple forwarding, async forwarding, load info, etc. After we implement the primitive - it is possible to expose them over multiple transports - socket, unix, etc and even marshal the messages using different libraries. We could even expose an API over plain HTTP ( without mux-ing ). I am only suggesting one marshal library ( at least for start ), and a small changes to the transport we have. The API can be something like: - legacyRequest(RequestMessage) - whatever we have in the current AJP protocol - getServerLoad() and whatever new we wanted to add Instead of defining AJP extensions, we just pick one of the marshalling libs and use them for encoding the new methods. Later we can add: - asyncInputData(reqId, Data) - on tomcat - asyncSendData(reqId, Data) - on web server For transport - we can keep most of the current code, but for async we need to stop waiting for a response to each request, and use a request ID ( or 'channel ID' ) and multiplex. I think this can be done without a huge effort, and incrementally - i.e. alongside the existing code, reusing what we have. Well, maybe I'm underestimating, but I'm pretty sure the harder part will be agreeing on details like what marshaling to use, what branch and review process - can anyone veto a proto/api he doesn't like, etc :-) That's why I'm suggesting that long term we could support multiple marshalling and API extensions, if there are strong religious reasons. In any case - there are quite a few mux protos out there - SSH proto, PPP, few in w3c /http.next, etc, and most can use any payload ( marshalling/api ). And for 'human readable' - I can throw in XMPP as an alternative to your wsgi :-) Costin > > >> >>> 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 > >
