Skip to main content

[jsr356-experts] Streaming Options

  • From: Danny Coward < >
  • To:
  • Subject: [jsr356-experts] Streaming Options
  • Date: Thu, 12 Jul 2012 16:46:22 -0700

Hi folks,

I'm going try to to reduce the thread on the various options on the streaming apis we've chewed on over the last week into three options. I *think* everyone agrees that applications should listen for incoming messages, rather than block until one arrives. Right ? So I think that leaves us with these three modes (below) for processing messages. (And note that I think we agree that nothing in the API is supposed to dictate anything about how the implementation uses web socket framing underneath.)

mode
receive description
possible receive API
send description
possible send API
1. "whole messages"
listen for incoming messages, get message all at once onMessage(String string)
onMessage(byte[] bytes)
send whole messages send(String string)
send(byte[] bytes)
2. "blocking read/writes"


listen for incoming messages, read message from stream using blocking calls onMessage(InputStream is) { ... byte b = is.read(); ...}
onMessage(Reader r) {  ...  int c = r.read();   ... }
open send stream, blocking writes to the stream OutputStream getSendStream()
Writer getSendWriter()
3. "async processing"
 

listen for incoming message, receive message from stream asynchronously Option A) onMessage(AsynchronousByteChannel abc)  {  abc.read(bytebuffer, attachment, completionhandler) }

Option B) 1 or more calls to onMessage(String partialString, boolean isLast) or onMessage(byte[] partialBytes, boolean isLast)

Option C) servlet 3.1-style special IO streams that allow non-blocking reads.
initiate outgoing message, message pulled on demand by the stream Option A) AsynchronousByteChannel getAsyncChannel()

Option B) 1 or more calls to send(String partialString, boolean isLast) or send(byte[] partialBytes, boolean isLast).

Option C) servlet 3.1-style special IO streams that allow non-blocking writes.


So I think in terms of what goes in the JSR API, mode (1) I think is a no-brainer for bread and butter applications, although obviously (1) alone would not be enough. I think Scott made a good case for (2) in terms of making it easy to use other libraries that assume traditional IO. I also think we should expose some form of mode (3), for frameworks that build on the API. I don't think it has to be either 2 or 3: it can be both.

Of the choices in mode (3), I'd probably go for option A). However, I do think many developers (me at least, but not Greg!) find the NIO APIs awkward, so can see a benefit in the simplicity of option B). The servlet style of specializing the Java IO APIs to allow non-blocking IO seems on the face of it to be overly elaborate for our needs, so I like option (c) least.

- Danny
--
Danny Coward
Java EE
Oracle Corporation


[jsr356-experts] Streaming Options

Danny Coward 07/12/2012

[jsr356-experts] Re: [jsr356-users] Streaming Options

Scott Ferguson 07/13/2012

[jsr356-experts] Re: Streaming Options

Greg Wilkins 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Streaming Options

Scott Ferguson 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Streaming Options

Greg Wilkins 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Re: Streaming Options

Scott Ferguson 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Re: Streaming Options

Greg Wilkins 07/14/2012

<Possible follow-up(s)>

[jsr356-experts] Streaming Options

Danny Coward 07/12/2012

[jsr356-experts] Re: Streaming Options

Joe Walnes 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Streaming Options

navraj . reddy 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Streaming Options

Justin Lee 07/13/2012

[jsr356-experts] Re: Streaming Options

Remy Maucherat 07/13/2012
 
 
Close
loading
Please Confirm
Close