On Wed, Feb 15, 2012 at 10:31 AM, Mark Thomas <ma...@apache.org> wrote:
> On 15/02/2012 16:11, Costin Manolache wrote: > > 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 :-) > > Sounds good. > > > 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'd love to drop the streams and just use the message based API but the > WebSocket protocol design is such that it needs to support streaming to > stand any chance of being remotely scalable / efficient given the > frankly crazy maximum message size. > I think it's not as bad, and crazy-size frame can be split - users need a callback when a new message started, than can call UpgradedProtocol.read([]) until the message is done. In spdy I'm using a SpdyFrame class ( spdy allow data frames to be fragmented any way you want by intermediary - so even if I receive a huge frame, I can split it in buffer-sized frames - I believe you can do the same for websocket, as long as you preserve the message boundaries), and return the real buffer to avoid the copy required for read(b[]). But of it involves a releaseBuffer(). Take a look - if/when we have websocket-over-spdy it would be good to be consistent. Costin > > Maybe after things have bedded in for a while, we'll see which API folks > are using and if there is zero demand for the stream based API we can > drop that part and simplify the code accordingly. > > > > I think most improvements I can think of involve removing code :-) > > Those are always my favourite changes. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
