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
>
>

Reply via email to