WebSocket client API

[Simone Bordet]

Hi,

On Tue, Oct 13, 2015 at 10:02 PM, Chris Hegarty
<chris.hegarty at oracle.com> wrote:
>> Here is a proposed mechanism for managing buffers used by Listener.
>
> I think that this is quite good. There is clearly a need for the receiving
> callbacks, onXXX methods, to allocate ( since they pass the payload
> as a ByteBuffer ), so exposing, through a small surface area, an API
> that gives better control over this allocation ( for the 0.1%that may
> want to do this ), without impacting on the 99.9% that couldn’t
> care less about it, seems reasonable. It is a nice side-effect that
> pinning / explicit release can be built on top of this, albeit with a
> small amount of work.

I am not sure I like it.
This being a WebSocket API, I am not sure that exposing ByteBuffer
pooling in the WebSocket API is a good idea.

I agree that there is a need to configure this, but seems to me more
an implementation detail or something you want to configure in a
concrete implementation class, rather than in the API.

IMHO there are other ways to solve the same problem than exposing a
ByteBuffer pool API inside a WebSocket API.

Thanks !

-- 
Simone Bordet
http://bordet.blogspot.com
---
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