[jetty-dev] jetty-9 websockets API

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Jesse/Joakime

I've moved this to jetty-dev where it should be.

I had a quick look at the proposed standard websocket API.... it does
not shout "I'm wonderful" at me.   However the interesting thing is
the feedback from others - there appears to be support for using
streams to send/receive large messages independently from frame
boundaries.   We should also look at it more closely to see if we can
get at least convergence on naming etc.

I can see the argument that frames are a transport artefact and should
not effect the application - so if messages are too large to fit in
memory then the application should not really have to deal with
frames.   Streams are good for this because they allow the application
to decide how big buffers to pass to a read or how bug a blob to write
- and these sized can be independent or at least decoupled from frame
size.

We brings me back to our current jetty-9 implementation and I think we
do need to review how we expose frames.

I'm not so sure we need different classes fro
Ping/Pong/Text/Data/Binary etc frames.   Specially for data, we cannot
apply any interpretation on the frames themselves.  it is only when
frames are aggregated into messages that we can say they are binary or
text.   Also I do see scope for extensions changing both the number
and type of frames as they are processed, so perhaps a single Frame
class is better than polymorphic types.   If we remove the UTF-8
processing from TextFrame, there is not much left of that class!

The WebSocketListener API is good because it delivers messages not
frames.   I guess the mood in JCP356 is to support methods like

  void onWebSocketBinary(InputStream in)

so that large messages can be delivered.  I think this gives a
threading problem as streams are blocking.  But we will have to
monitor where that goes.

On the otherside, WebSocketConnection has a write(BaseFrame frame)
method.   I think that is wrong.  Applications write messages not
frames and it is our implementations job to turn messages into frames.

We do have message writes as well - so I think we need to have a
different interface that allows frames to be written (and that would
be the interface exposed to extensions that are frame aware).

I like
    void write(ByteBuffer... buffers) throws IOException;
    <C> void write(C context, Callback<C> callback, ByteBuffer...
buffers) throws IOException;
    <C> void write(C context, Callback<C> callback, String...
messages) throws IOException;

but why
    void write(String message) throws IOException;
instead of
    void write(String... message) throws IOException;

are the methods without callbacks meant to be blocking? the javadoc
says non-blocking?


I then think we need to have the extension API have a mechanism for
sending/receiving frames (not messages).
The Parser.Listener interface fits the bill for receiving frames, but
WebSocketConnection is not right for sending.  We need another
abstraction between the connection the application sees and the
Generator.  ie AsyncWebSocketConnection cannot call the generator
directly, but will call sendFrame on some new abstraction, that will
pass the frame through all extensions before calling the generator.


cheers









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