On Mon, Feb 20, 2012 at 16:19, Mark Thomas <ma...@apache.org> wrote: > 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. > Yes, except that the java CharsetDecoder didn't seem to think that UTF-8 sent by Autobahn as invalid was indeed invalid. At least was my impression, but I might very well be wrong.
> > 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'll try to pull these during the weekend, maybe it'll still be useful. > 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. > Thanks! > > 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 > >