On 08/02/2013 12:47, Joakim Erdfelt wrote:
> If I saw that API as an end user, I would assume passing in 4 ByteBuffers
> would result in 4 binary messages, not 1 binary message of all the bytes
> together.
We could make the expected behaviour clear in the Javadoc.
I'm neutral on this one. On the plus side I can see how it might be
useful. On the down side there are already a lot of sendXxxx methods and
I don't particularly like the idea of adding even more.
What could work would be to re-order the parameters and use a varags.
Something like:
sendBytesByCompletion(SendHandler completion, ByteBuffer... data);
That way the user isn't faced with even more methods and can send single
of multiple ByteBuffers as they desire.
Mark
>
> --
> Joakim Erdfelt <joakim_at_intalio.com>
> webtide.com <http://www.webtide.com/>
> Developer advice, services and support
> from the Jetty & CometD experts
> eclipse.org/jetty - cometd.org
>
>
> On Fri, Feb 8, 2013 at 1:47 AM, Norman Maurer <nmaurer_at_redhat.com> wrote:
>
>> Hi,
>>
>> I wonder if it would be possible to add another method for every
>> RemoteEndPoint.send*(..) method that takes a ByteBuffer. The new method
>> should look the same but take a ByteBuffer[] as argument .
>>
>> So for example add this method:
>>
>> void sendBytesByCompletion(ByteBuffer[] data, SendHandler completion);
>>
>>
>> It would allow the user to reuse ByteBuffer and combine a few to one
>> payload without the need to allocate a new one that can hold the whole
>> payload, This also gives better support for Buffer pools with fixed size
>> buffers.
>> Implementations could then use gathering writes if they are based on NIO
>> to write them out in an efficient manner. If not based on NIO it should be
>> easy for them to just handle it by copy the contents.
>>
>> ---
>> Norman Maurer
>> nmaurer_at_redhat.com
>>
>> JBoss, by Red Hat
>>
>>
>>
>>
>