mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Fwd: Re: [MINA 3.0] Buffer Design
Date Thu, 13 May 2010 08:57:21 GMT
Forwarded to the ML...

On Mon, May 10, 2010 at 1:51 PM, Emmanuel L├ęcharny<elecharny@apache.org>  wrote:
>  On 5/13/10 10:01 AM, Ashish wrote:
>>  Sorry for reverting a bit late
>>  Here are my confusion
>>  1. We talked about removing IoBuffer interface and using ByteBuffer
>>  directly. Is this what are implementing or we plan to keep IoBuffer?
>  We don't want a wrapper around ByteBuffer if it's just to offer a way to
>  extend the buffer. You have to understand why IoBuffer has been created from
>  day one : ByteBuffer cannot be extended (ie add more bytes than what were
>  allocated), and you can't extend (ie class MyBuffer extends ByteBuffer...)
>  ByteBuffer because the constructor is not public. So the IoBuffer has been
>  created, a wrapper around ByteBuffer just for this purpose.
>  IMO, it defeats the idea that a Buffer is just a temporary storage. It's
>  created once, and then used but not modified. By defining a class that
>  stores many ByteBuffers, but with methods that mimic the ByteBuffer class,
>  you can have a better solution, as you don't reallocate a new buffer each
>  time you want to extend it. So the idea is just to have a class in which you
>  concatenate the incoming ByteBuffers but that is seen as a single
>  ByteBuffer.

You put precise words to my thoughts :) Yeah we really don't need to
have all the methods of BB, but a class that
can give a unified view of Buffers. This is what was running in my
mind, but yeah I overlooked other API's in IoBuffer..

>>       With IoBuffer, Users may implement their own buffer's. With direct
>>  use of BB, we loose this. I am not sure if anyone would ever need to
>>  implement
>>       this, but its worth considering as remote possibility and reject it.
>  I hope I clarified the matter.
>>  2. I am not sure if Zero copy is at all relevant here, but I am
>>  confused. When we write back response, we usually use what's in the
>>  Buffer, so how  does it work? I am essentially mixing things here, but
>>  in isolation its difficult to put things together.
>  Zero copy is important when you want to transfert large chunks of data to
>  the client. For instance, when writing a FtpServer, you don't want to read
>  the file from the disk into a temporary memory, just before writing it back
>  to the socket, unless you have some transformation to do on the data. In
>  this case, what you want to do is to directly read from the file and move
>  the data to the channel. The FileChannel API contains a transferTo() method
>  that does exactly that. We have to use it.

Hmm in this case our buffer's should not come in picture :) it should
go directly to the Channel.

>>  There are a few more questions, but things are little mixed up at my
>>  end. Shall send them out soon...
>  Hope it helps.

Yeah it does :)

There is lot of context switching happening at my end :(
I am really not able to put in the amount of effort I planned for 3.0 :(

Hope things will improve in future :)


View raw message