Skip to main content

[jsr356-experts] Re: High level Requirements and Example scenarios

  • From: Scott Ferguson < >
  • To:
  • Subject: [jsr356-experts] Re: High level Requirements and Example scenarios
  • Date: Sun, 22 Apr 2012 17:10:25 -0700

On 04/20/2012 03:29 PM, Danny Coward wrote:
" type="cite"> 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







[jsr356-experts] High level Requirements and Example scenarios

Danny Coward 04/20/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Mark Thomas 04/22/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Scott Ferguson 04/22/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Scott Ferguson 04/23/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Greg Wilkins 04/24/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Wei Chen 04/24/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Remy Maucherat 04/24/2012

[jsr356-experts] Re: [jsr356-users] Re: High level Requirements and Example scenarios

Justin Lee 04/24/2012
 
 
Close
loading
Please Confirm
Close