Option 1 and 3B both are fine by me. Having both makes it slightly akward
in some ways. While #1 is great for smallish messages (which are likely to
be commonish depending in the frame size), it can lead to mild
confusion/duplication when app authors will need to include/call logic from
both methods to handle incoming data that may or may not be broken across
frames. Even with an explicit frame size requested, intermediaries are
allowed to break up frames based on whatever criteria they need, iirc.
This all just serves to obscure where the bulk of the logic should lie if
both are exposed. Personally, I'd be fine with just 3B where most of the
time isLast is always true.
On Fri, Jul 13, 2012 at 9:25 AM, <navraj.reddy_at_gmail.com> wrote:
> Looking at the other services API, it looks like at the minimum we need
> To implement option # 1 and option # 3c
>
> Where we need synch and asynchronous support. Option #2 seems
> To be good but looks complex as the main thread have to be blocked
> Until the whole message comes back. I would go with option #2
> If we are reading big blog data.
>
> It would be good to extend as some people like the data read byte
> By byte for better performance.
>
> Thanks
> Naveen
>
>
>
> On Jul 12, 2012, at 9:23 PM, Joe Walnes <joe_at_walnes.com> wrote:
>
> I'm also a fan of 3B with 1 layered on top for convenience.
>
> On Thu, Jul 12, 2012 at 6:46 PM, Danny Coward <danny.coward_at_oracle.com>wrote:
>
>> 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
>> --
>> <http://www.oracle.com> * Danny Coward *
>> Java EE
>> Oracle Corporation
>>
>
>
--
You can find me on the net at:
http://antwerkz.com http://antwerkz.com/+
http://antwerkz.com/twitter http://antwerkz.com/github