On 29 January 2012 10:19, Mark Thomas <ma...@apache.org> wrote: > 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.
May I suggest that such design decisions are documented in the code and/or package Javadoc? > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
