Hi Scott, all,
Thanks for the feedback, pls see below:-
>>
>> Issues covered in v002
>>
>> * Message representation: The API presents messages as String, byte[]
>> and Iterators thereof. No nio classes, no IO streams. The goal of
>> this approach was to allow buffered messages (for convenience) and
>> chunked messages (for efficiency) without limiting the implementation
>> choices IO/NIO/combination of implementors of the API.
>
> Without streams, it's not a serious proposal.
>
> Chunking/framing is a low-level implementation/protocol detail related
> to implementation buffering; it's not visible at the API-level. The
> fact that the draft introduces an iterator to simulate a stream should
> by itself be an indication that something is wrong.
>
> Ask yourself this: is HTTP chunking visible to a servlet? No.
>
> The servlet API has a simple stream interface, and has been extremely
> effective.
OK. So we can certainly add streaming to process messages.
But, are you suggesting using blocking Java i/o streams, like the
servlet api, to represent that ? Something similar or equivalent to:-
WebSocketListener -> public void onMessageAsInputStream(InputStream is)
RemoteEndpoint -> public OutputStream startSendByOutputStream() ?
And possibly exploring the type of additions that would allow
non-blocking IO based on the traditional i/o streams as well, such as
the servlet expert group has been looking at for servlet 3.1 ?
Although at least one of the APIs allows this, most APIs seem to favor a
type of asynchronous processing same as or equivalent to:-
WebSocketListener-> public void onMessage(byte[] fragment, boolean isLast)
RemoteEndpoint-> public void send(byte[] fragment, boolean isLast)
What are people's thoughts on standardizing this kind of chunking API ?
- Danny
>>
>>
>> --
>> <http://www.oracle.com> *Danny Coward *
>> Java EE
>> Oracle Corporation
>>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation