On Wed, Feb 15, 2012 at 12:34 AM, Mark Thomas <ma...@apache.org> wrote:
> > > Processor is tied to one request/response - Spdy protocol is a > multiplexing > > protocol, so one spdy connection will have 100s of Requests. > > I am using Processor interface for each muxed spdy stream. > > Hmm. I wonder if we need a different name than Processor just to clarify > the difference? But that is more a cosmetic issue. > It's probably too big change. Maybe some more javadocs ( I added a few where I had to figure things out ) :-) > > Plus - both are quite rich objects. I think it's worth using a smaller > > interface > > ( i.e. Endpoint.Handler with few extra extensions). > > I'd be prepared to trade a little bit of extra baggage (as I have with > much of the connector refactoring) to increase commonality between > components and reduce code duplication. What that means for SPDY I don't > know yet. Again, I need to look at your latest proposal. This is more a > general statement of the compromises I am happy making for easier > maintenance. > I agree in general. What I'm trying to do with spdy is keep the spdy package mostly dependence-free, with the tomcat specific code well isolated. After I submit, I'll give a try to changing SocketWrapper (non-generic, add read/write), in the git. If you don't like it - easy to drop the branch, but I think it'll simplify the old connectors enough to compensate for the extra complexity I'm adding :-) > >>> Also: the current upgrade is quite heavy, it holds Requet/Response and > a > >>> bunch of > >>> buffers. > >> > >> No it doesn't. Take another look at the code. The original > >> implementation did but as I stated at the time my intention was to do > >> some further refactoring to fix that. That refactoring has been complete > >> (and is what resulted in the API changes I was referring to previously). > > > > Yes, much better now ! ( but still I don't think it's the best fit ). > > Thanks. Suggestions for improvements welcome. > Well, UpgradeProtocol has read/write methods, I would drop the streams ( keep them as separate util classes if someone wants them). I would also drop the methods reading/writing a single byte, use only byte[]. I think most improvements I can think of involve removing code :-) > For non-SSL ( JIO, and apr without ssl ) -> SPDY just kicks in on all > > connections, > > Ah. Light dawns. Do you see a requirement for non-SSL connections to be > able to use HTTP or SPDY in the same way SSL ones can? For the proxy use > case, an assumption of all SPDY seems valid. > Yes, there is a special header that needs to be set ( if tomcat SPDY is working ), browsers will stop sending http and switch to spdy ( they'll also remember for next time ). Costin > > > this is just a short-cut for testing. I could also define a SpdyProtocol > > and set it > > directly on the connector - but seems too much overhead for something > that > > is testing/experimental. > > Cheers, > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
