On 29/01/2012 01:20, Costin Manolache wrote: > On Fri, Jan 27, 2012 at 3:09 PM, Mark Thomas <ma...@apache.org> wrote: > > Not complaining - it's great to add this feature, please commit it - but > I'm wondering > if a lighter interface wouldn't be better. From looking at the > implementation, it seems > after the upgrade it keeps the InputBuffer/OutputBuffer ( and the whole > Request / Processor / etc tree ).
I agree there is certainly scope to do that. My initial focus has been on functionality and minimal changes to existing code - hence the current approach. I'm not overly keen on the additional overhead myself and can see several ways to reduce it. Output is easier than input since we know the output buffers are clear on upgrade. Input is a little trickier since there may be some data in the input buffer and that would need to be drained before switching to the lighter weight approach. I think this is something to look at once the implementation is more feature complete. Whatever we do, I'd like to keep the following aims in mind: - minimal endpoint specific code - minimal changes to what we have now - keep the generic upgrade and the protocol specific parts separate > Would it be possible for example to release the Request, like it's done > after request, > in keep-alive, and use a lighter parser/callback on the socket ? I think > one of the use cases > for websockets is to support a _lot_ of open connections. That is certainly one approach. It will be easier to explore options when we have a wider range of examples to work / test with. > Also the interface may be simpler without InputStreams. I thought long and hard about that. Looking around, some implementations are message based, some are stream based. There are good arguments for both. Unfortunately the WebSocket protocol is a messages based protocol with no maximum message length. A message is one or more frames and a frame is up to 2^63 bytes. While most usages will be small(ish) messages that can be buffered without undue overhead, any application that wants larger messages needs to use a stream based interface to be able to scale. That is why I went for both. Thanks for the feedback. Much appreciated. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
