Hi Stuart,
thanks for kicking this off..
I think this makes sense and should be a good "base" for a high-level API.
Let me do some more testing and integrate the idea in my websockets effort under (it's
still in an early stage):
https://github.com/normanmaurer/undertow/tree/websockets
Bye,
Norman
Am 09.10.2012 um 10:30 schrieb Stuart Douglas <sdouglas(a)redhat.com>:
Hi Guys,
So I have just been thinking about the low level web socket API, and basically I think it
should look something like:
class WebSocketChannel {
/**
* Async receive, returns null if no frame is ready. Otherwise returns a channel that
can be used to read the frame contents.
*/
StreamSourceFrameChannel receive();
/**
* Returns a new frame channel for sending. If this is called multiple times subsequent
channels will not be writable until all previous frame have been completed.
*/
StreamSinkFrameChannel send();
/**
* Lister to call when a new frame is ready
*/
ChannelListener.Setter<? extends WebSocketChannel> getReceiveSetter();
ChannelListener.Setter<? extends WebSocketChannel> getCloseSetter();
}
Basically once the connection is established, this channel can be used to get
FrameChannels to send and receive frames. A FrameChannel will act like a normal
Source/Sink Channel, however with some extra methods for determining the type of frame.
the undertow integration will consist of a handler that performs the initial handshake,
and set up the connection. Once the handler has creates this WebSocketChannel, it hands it
off to the user (the user will register a ChannelListener with the handler for this
purpose), and this is where Undertow core stops having anything to do with the connection,
and the web socket library takes over.
All higher level web socket functionality will be based on this low level API.
Thoughts?
Stuart