On Wed, Mar 25, 2009 at 9:12 AM, Henri Gomez <henri.go...@gmail.com> wrote:
> 2009/3/25 William A. Rowe, Jr. <wr...@rowe-clan.net>: > > Mladen Turk wrote: > >> > >> The problem with mod_proxy and mod_cluster is the > >> fact they are targeted for a *single* web server (httpd) > > > > Which varies from a one off poorly defined protocol how, exactly? > > > >> They don't have the generic web server API like mod_jk > >> does, and all of them doesn't support async behavior. > >> There is simply limitation in both AJP13 and Httpd protocol > >> that prevents something like that if one wish to > >> have both async, secure and persistent connections > >> from the web server to the app server. > > > > HTTP protocol inhibits this how, exactly? > > HTTP could be persistant and secure, but certainly not async. > > It's still a synchronous protocol, a request and a reply some time later. > No unsolicited messages from server to client (browser) for example. > > BTW, mod_jk / ajp were designed to relay HTTP requests and so are very > HTTP 'compliants'. > Yes, async and bidirectional are the big ones, and http doesn't help ( http-mux maybe ). I agree AJP protocol is worse than HTTP and the binary encoding is no longer a big deal, ajp13 should slowly ( or quickly ) die. But I don't think we should start inventing another protocol - there are plenty good ones. For marshalling, apache-thrift (from sandbox ) or protobufs ( apache-license ) are more than enough and have both native and java implementation. For RPC/framing - there's plenty of code around too. This thread was more about where to implement new features - if the goal is a 'redesign from scratch' than maybe sandbox or a branch is a better place, but we tried that twice (jk2 and webapp) and I don't think there are enough people interested in such an effort - development nor testing. Adding the features to the existing code - with the extra effort to not break existing functionality - IMO has a better chance of success. Costin
