[JBoss JIRA] Updated: (NETTY-96) ChannelBufferFactory

[Trustin Lee (JIRA)]

     [ https://jira.jboss.org/jira/browse/NETTY-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee updated NETTY-96:
-----------------------------

    Description: 
The default buffer type of Netty 3.0 was a heap buffer.  It was possible to create a direct buffer, but it was not supported as a first class citizen.  Also, a user might want to implement one's own buffer type (e.g. JNI-based proprietary implementation).

To address this issue, I will add the following methods:

  * ChannelConfig.getBufferFactory() - returns the factory that creates the receive buffer of I/O thread
  * ChannelBuffer.factory() - returns the factory that creates the same type and byte order with the callee buffer

Once a buffer is created by ChannelConfig.getBufferFactory().getBuffer(capacity), a slice of the created buffer will be the content of the generated MessageEvent, which means you have full control over what buffer type you want to get in your handler (e.g. decoder).

Also, FrameDecoder, ReplayingDecoder and other out-of-the-box handlers and codecs should respect the factory of the buffer it received when it tries to create a new buffer so that the user handler implementation gets the buffer of the expected type.

At last but not least, a user should not be enforced to respect the buffer type - existing user code should work as it did and a user should be allowed to create a new buffer by calling ChannelBuffers.* instead of calling ChannelBufferFactory.getBuffer() as one did.

  was:
The default buffer type of Netty 3.0 was a heap buffer.  It was possible to create a direct buffer, but it was not supported as a first class citizen.  Also, a user might want to implement one's one buffer type (e.g. JNI-based proprietary implementation).

To address this issue, I will add the following methods:

  * ChannelConfig.getBufferFactory() - returns the factory that creates the receive buffer of I/O thread
  * ChannelBuffer.factory() - returns the factory that creates the same type and byte order with the callee buffer

Once a buffer is created by ChannelConfig.getBufferFactory().getBuffer(capacity), a slice of the created buffer will be the content of the generated MessageEvent, which means you have full control over what buffer type you want to get in your handler (e.g. decoder).

Also, FrameDecoder, ReplayingDecoder and other out-of-the-box handlers and codecs should respect the factory of the buffer it received when it tries to create a new buffer so that the user handler implementation gets the buffer of the expected type.

At last but not least, a user should not be enforced to respect the buffer type - existing user code should work as it did and a user should be allowed to create a new buffer by calling ChannelBuffers.* instead of calling ChannelBufferFactory.getBuffer() as one did.



> ChannelBufferFactory
> --------------------
>
>                 Key: NETTY-96
>                 URL: https://jira.jboss.org/jira/browse/NETTY-96
>             Project: Netty
>          Issue Type: Feature Request
>          Components: Buffer
>            Reporter: Trustin Lee
>            Assignee: Trustin Lee
>             Fix For: 3.1.0.ALPHA3
>
>
> The default buffer type of Netty 3.0 was a heap buffer.  It was possible to create a direct buffer, but it was not supported as a first class citizen.  Also, a user might want to implement one's own buffer type (e.g. JNI-based proprietary implementation).
> To address this issue, I will add the following methods:
>   * ChannelConfig.getBufferFactory() - returns the factory that creates the receive buffer of I/O thread
>   * ChannelBuffer.factory() - returns the factory that creates the same type and byte order with the callee buffer
> Once a buffer is created by ChannelConfig.getBufferFactory().getBuffer(capacity), a slice of the created buffer will be the content of the generated MessageEvent, which means you have full control over what buffer type you want to get in your handler (e.g. decoder).
> Also, FrameDecoder, ReplayingDecoder and other out-of-the-box handlers and codecs should respect the factory of the buffer it received when it tries to create a new buffer so that the user handler implementation gets the buffer of the expected type.
> At last but not least, a user should not be enforced to respect the buffer type - existing user code should work as it did and a user should be allowed to create a new buffer by calling ChannelBuffers.* instead of calling ChannelBufferFactory.getBuffer() as one did.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira