Content ChannelBuffer Factory for HTTP Codec?

Trustin Lee tlee at redhat.com
Mon Dec 8 04:48:59 EST 2008


Hi,

Does this improvement satisfy your requirement?

  * https://jira.jboss.org/jira/browse/NETTY-96

By setting the default buffer factory to your own implementation, you
can decide what buffer type HttpMessageDecoder will use.

However, it's somewhat different from your original suggestion; Netty
uses the factory from the point where it allocates a receive buffer,
which means your native buffer implementation will be used throughput
the framework.  If it's not what you expected, we could improve the
design of the current ChannelBufferFactory interface.

HTH,
Trustin

On Wed, Dec 03, 2008 at 11:46:21PM +0900, Wade Poziombka wrote:
> 
> Thanks for your prompt reply!
> 
>  
> 
> We do need chunked encoding but my issue is more that ultimately I need the
> content in buffer(s) of my own.  
> 
>  
> 
> My suggestion is to allow me to provide a ChannelBuffer that wraps my own
> buffer(s) for the content portion of the message.  In order to do so I would
> need to provide some kind of a factory to the decoder.  This way as the
> decoder is decoding message content (chunked or otherwise) it could be put
> into my own buffer.  For example if a method on HttpMessageDecoder I could
> supply an object that has method similar to:
> 
>  
> 
> public interface ContentChannelBufferFactory
> 
> {
> 
>     ChannelBuffer createContentBuffer(ChannelContext ctx);
> 
> }
> 
>  
> 
> Then I could provide a buffer that will receive the content from the decoder
> into the buffers without additional copies (or buffering the entire
> message).
> 
>  
> 
> I could modify the encoder myself but under LGPL I would then have to
> publish my code.  Looking at the code it seems quite easy to do technically.
> However, this is difficult legally.  
> 
>  
> 
> Wade
> 
>  
> 
 
-- 
Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
--
what we call human nature in actuality is human habit
--
http://gleamynode.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20081208/1c050cc5/attachment.bin 


More information about the netty-users mailing list