On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk <mt...@apache.org> wrote:
> On 02/16/2010 06:57 PM, Costin Manolache wrote: > >> >> I think the main driver for replacing ajp is the 2-directional protocols - >> and if we >> replace it, why invent a new protocol and not just adopt SPDY, which has >> all >> we need. >> >> > Totally agree. > Both JK and AJP originate from days when the single server behind > web server was the common topology and when there was no async processing. > Beside SPDY, which some ASF folks that made a significant contribution > to the original HTTP specs consider as unperfect, there is BWTP proposal > (http://bwtp.wikidot.com/) > > SPDY has quite a few problems - but it's still an improvement over AJP and adds 2-directional and mulitplexing to HTTP - which is what we need. The main problem with a protocol is getting enough critical mass to overcome it's problems - HTTP is not perfect either. The reasons I suggest using SPDY as a replacement for AJP - and supporting SPDY out-of-box in tomcat: - it does what we need - there is one browser supporting it - and likely to take advantage of it - probably there will be at least one large domain using it :-) - There is also a mod_spdy for apache, and I'm sure there will be more. Regarding problems, my list is not very big: - requirements for compression and SSL - we don't need this for apache-tomcat communication. But it's easy to extend or configure the protocol to skip it / negotiate. - right now they only want to do it over 443 ( i.e. use CONNECT method ) to make sure proxies won't get in the way. Apparently UPDATE doesn't work in some places. That's also something we can extend - and seems to be due more to the desire to get something deployed. - of course - the current next-protocol SSL extension is out of question for java - which has problems even with the SSL session ticket. We might be able to support it with APR/openssl. - some cosmetic issues - I would prefer protobufs or thrift instead of yet-another binary format, sending the url as a header seems strange, binary header could be smaller, the server push is also a bit more complex than it should be. I don't think any matters, working around http is much worse. - I'm waiting for the flow control to be finalized - but seems reasonable. > Extending exiting protocols or just doing a 'quick hacks' like I > see with many projects trying to address those issues will not > work in the long run. At the end you will be faced with the > clean drawing board. There is never a 'clean drawing board', or a perfect protocol. Any new protocol needs to be adopted and needs to deal with existing infrastructure - proxies, blocked ports, timeouts in NATs, etc. BWTP doesn't seem so much better - mostly cosmetics. It's also more focused as a websocket - not as a browser-proxy-server protocol. And the list of implementations and potential adoption matters a lot for protocols. ( BTW: I write this wearing my own hat, my work on tomcat-lite and spdy is on my own time, etc ) Costin > > > > > Regards > -- > ^TM > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
