On 20/02/2012 21:28, Petr Praus wrote: > I'm glad to hear that. > > BTW, Jonathan quite significantly overhauled our implementation over the > weekend. The WebSocketFrame no longer buffers data but just stores a > reference to inputstream from which the data can be read by the client code > receiving the frame. This is not exactly what you originally implemented > but I think it's conceptually the same.
That sounds much better (I haven't looked at the code in detail). > In the future it would desirable to > shield client code from the WebSocketFrame itself and just provide streams. Indeed. That is how the current implementation in trunk works. > I personally think of WebSocketFrame as being more useful to internal > protocol logic than client code which very often does not care about most > of the stuff captured in the frame, just the data. Agree completely. > I added some fixes yesterday and the code now passes all Autobahn tests > including proper closes and close status codes. Very nice. That is better than the current trunk can manage. > The only exception are > UTF-8-related tests which require reading whole payload and checking that > its valid UTF-8. Haven't looked too hard at those yet. Assuming Java can tell the UTF-8 is invalid then handling that should be easy. > Unfortunately it's no longer easily mergeable with current trunk because of > your fragmentation changes on Friday, but if you would be willing to look > at it anyway, it's available in our GitHub repository: > https://github.com/praus/tomcat (the repository is a fork of the official > github apache/tomcat mirror). That is pretty much inevitable when you have a large patch and one of the main reasons I am trying to keep to small incremental changes in trunk. There are some of those trunk changes (I am thinking of AbstractProcessor) that you'll need to pull into your fork. I am borrowing from your fork where I can and am providing credit in the commit message so you can see what I have used. You'll also get credit in the changelog along with the other folks that have contributed code to the WebSocket impl. Based on progress today, things should move along pretty quickly. Next step is to get ping/pong working. Mark > > Petr > > On Mon, Feb 20, 2012 at 14:35, Mark Thomas <ma...@apache.org> wrote: > >> On 20/02/2012 10:04, Mark Thomas wrote: >>> On 20/02/2012 02:55, Petr Praus wrote: >>>> but I wanted to ask - have you considered using Autobahn for >>>> testing? It's rather extensive opensource websocket testing suite. >>> >>> I haven't. I just took a quick look. Looks like a nice tool. My test >>> client is intended to be something we can run in the unit tests to look >>> at very specific issues. It isn't intended to be a general WebSocket >>> client, nor to test the full range of functionality. I think Autobhan is >>> something we would run separately - a bit like we do with the WebDAV >>> test suite and the TCKs. >> >> I've been looking at this today and so far, my experience has been very >> good. Thanks for the tip. It has been really useful. >> >> I now have all the framing tests passing but the message close is >> currently unclean. Next step will be to fix that by adding support for >> close. >> >> 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
