On 04/20/2012 03:29 PM, Danny Coward wrote:
> Hello experts,
>
> Before we get to APIs and all that, I want to spend a little time
> talking about the high level requirements of the JSR. These were more
> or less laid out in the JSR itself, so that's always a good place to
> check back on as we get deeper into this.
>
> But I've laid them out again (attached document), together with the
> deployment settings, and a short description of an example application
> and how it all works that uses the output of the JSR.
Two ideas I've been wondering whether they should be in scope are:
1. message queuing (basically dealing with websockets as a
multithreaded messaging service)
2. encoding/decoding
Originally, I'd considered both out of scope, but they're both fairly
central to something structured like the chat application, and may be
easier/cleaner to handle from the implementation.
1. Why queuing may make sense: when the chat broker sends a message, it
cannot get stuck on any client, even if that client happens to be stuck,
otherwise the whole system freezes. If the API offers a queue, the
broker can dump a POJO message object in a client queue, and rely on the
implementation to wake threads, handle stuck clients, etc.
2. Encoding/decoding may make sense in conjunction with #1. The queued
POJO needs to be encoded before sending, for example to JSON. If the API
provides a simple encoding interface, plugging in standard JSON (or XML
or Hessian or protobuf or whatever) should be straightforward and reusable.
I'm not suggesting anything complicated, I hope. Something like:
// similar in concept to AsyncContext
public interface WebSocketContext {
// create queue for #1
public <T> BlockingQueue<T> createOutputQueue(WebSocketEncoder<T>
encoder);
// low-level stream (used by applications not using #1 and the
encoder for #2)
public OutputStream startBinaryMessage();
public PrintWriter startTextMessage();
}
// encoder for #2
public interface WebSocketEncoder<T> {
public void encode(WebSocketContext ws, T value);
public void flush(WebSocketContext ws);
}
Neither #1 nor #2 are strictly necessary, since a framework could
provide them, but they might be fundamental enough to discuss for this
JSR. (The chat example would need something like it.)
-- Scott