On Tue, Feb 14, 2012 at 3:29 AM, Costin Manolache <cos...@gmail.com> wrote: > Ok, took a bit to get the Apr polling to work and add some minimal tests. > > Please take another look - in particular to > https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java > > The spdy implementation seems to work with chrome, and the client seems to > work with google. > Probably still has plenty of bugs - but it's a start. > > If no objections - I'll start merging the LightProtocol/util.net changes > first, than add the spdy server implementation. The spdy client and tests - > probably later, I want to clean them up a bit more.
+1. I took a look at the previous rev of the patch, not the latest. Yoav > > Costin > > > On Thu, Feb 2, 2012 at 6:37 AM, Mark Thomas <ma...@apache.org> wrote: > >> On 02/02/2012 14:14, Costin Manolache wrote: >> > On Thu, Feb 2, 2012 at 3:33 AM, Mark Thomas <ma...@apache.org> wrote: >> > >> >> On 02/02/2012 10:05, Remy Maucherat wrote: >> >> >>> Ok, I think your "light protocol" concept to group any "upgraded" >> >>> connections is appropriate. >> >> >> >> Agreed. I'll see if I can wrap this into the generic upgrade process I >> >> added as part of the WebSocket support. >> >> >> > >> > My concern with the current upgrade process added for WebSocket is that >> > it's very heavy >> > in memory use. >> >> That is what I was agreeing with. I meant that I'll see if I can turn >> the current heavy-weight upgrade process into a light-weight one. As I >> have said before, this is already on my to-do list. I'll bump it up and >> start on it now so you have something to work with in trunk. I can steal >> ideas of you along the way :). That way we can hopefully get something >> pretty quickly into trunk that works for WebSocket and SPDY. >> >> > I think it would be better to go the other way - and use the >> > LightProtoocl for WebSockets. >> >> Exactly. >> >> > If the app needs the original >> > Request/Response - we could >> > save them, but in most cases I don't think they'll be needed. >> >> I don;t see the need for that. >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
