Re: [jetty-dev] jetty-9 websockets API

[Greg Wilkins <gregw@xxxxxxxxxxx>]

(dang! 3 attempts to get it into the right list!)

I'm not going to inline, to avoid infinite nesting.  Instead will
respond topic by topic.

Just because we move the UTF-8 processing from the frame to the
message level does not mean that it cannot fast fail.

If we are aggregating frame by frame into a single message String,
then we can use the UTF-8 String builder class, which will fast fail
any invalid sequences, but also handle partial appends of multi byte
characters.

If we are streaming (or some other chunk by chunk delivery mechanism
to avoid holding complete messages), then we might have to modfiy
UTF-8 String Builder so that we can take all completed characters
while leaving the state of any partial characters.

I think this change is the most important thing to do - ie moving
behaviour from frame to message level - because we can then look at
the code left over in the Frame classes and see if the polymorphism is
needed or not.  I don't think it will be, but let's see.

This message layer could be done in a new layer or I think it could
also be done in the  WebSocketEventDriver.   I don't think it right to
call it an aggregation layer, because if we stream (or similar) it
will not be aggregating, but instead extracting partial messages
(trivial for binary, not so hard for utf-8).

On 4 July 2012 00:53, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
> How about we fix the TextFrame validation for now, and re-evaluate maybe
> going back down to 3 frame types (BaseFrame -> (DataFrame | ControlFrame))
> within the next few weeks (as we start integrating the extension chain back
> into the mix).

+1 (ok one inline response :)


-- 
Greg Wilkins <gregw@xxxxxxxxxxx>
www.webtide.com
Developer advice, services and support
from the Jetty & CometD experts.