WebSocket

[Chris Hegarty]

The conversation has gone a little off topic from the WebSocket API,
and this is probably not the best place to be discussing such proposed
convenience / performance APIs, since they need broader discussion
than net-dev.

It seems most folk are in agreement that the proposed WebSocket API
could be used as a foundation to build the desired higher-level
abstractions that have been asked for on this thread. I see this as a win
for the proposed low-level Java SE WebSocket API. It is supposed to
be a building block, not a complete building.

-Chris.

> On 20 Feb 2018, at 10:52, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> Hi,
> 
> On Tue, Feb 20, 2018 at 10:22 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> 
>> On 20/02/2018 08:14, Simone Bordet wrote:
>>> 
>>> :
>>> Where would be a good list to start discussing ByteBuffer to
>>> [Input|Output]Stream bridging ?
>>> 
>> Are you looking for this for performance or convenience reasons?
> 
> Convenience.
> 
>> Bridging channel and input/output streams is natural of course, bridging between
>> buffers and input/output streams hasn't come up very often. ByteBuffer
>> defines bulk get/put methods so it's trivial for anyone to wrap byte buffers
>> if they need to.
> 
> Sure, it just would be handy the JDK provided this rather than users
> rewriting the same utility class.
> 
> For example, having:
> 
> OutputStream.write(ByteBuffer)
> InputStream.read(ByteBuffer)
> 
> avoiding intermediate copies to byte[] but also:
> 
> ByteBufferInputStream.offer(ByteBuffer b, boolean last)
> 
> to feed ByteBuffers to the InputStream and be able to read them via
> normal byte[].
> 
> Something along these lines.
> 
> Thanks !
> 
> -- 
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz