[Repost] New ChannelBuffer type proposed

[Frederic Bregier]

Hi Trustin,

I'm agree that we could replace CompositeChannelBuffer with this one (so not
introducing a new name).
I had done like this in order to allow anyone to test it without removing
CCB from Netty.
Now that you think it is ok, I will propose you the new code for CCB using
the one from the Aggregate.

For wrappedCheckedBuffer, in fact, it was strictly in the same mind that for
CCB, that is to say that I did not wanted to remove the default
wrappedBuffer from ChannelBuffers. But of course, I would propose you the
patch for ChannelBuffers such that wrappedBuffer take care of this without
introducing any new method...

Give me a day or two (at least before the end of the week-end), and I will
post a new set of java code (replacement for CompositeChannelBuffer and its
Junit test, and the patch for ChannelBuffers).
Are you ok with this ?
I could also directly patch on trunk but if you don't mind, I would prefer
you check a last time before comiting, ok ?

Cheers,
Frederic



Trustin Lee wrote:
> 
> Hi Frederic,
> 
> The code looks OK, but I'm still not sure if we need to make
> wrappedCheckedBuffer() public.  We could modify
> ChannelBuffers.wrappedBuffer() to recognize composite buffers using
> instanceof.
> 
> Also, if your implementation works in the same way with
> CompositeChannelBuffer, then we could simply replace it with your
> buffer type and rename it to CompositeChannelBuffer, rather than
> introducing a new name?
> 
> Thanks for your patience
> 
> — Trustin Lee, http://gleamynode.net/
> 
> 
> 
> On Thu, Sep 10, 2009 at 5:13 AM, Frederic Bregier <fredbregier at free.fr>
> wrote:
>>
>> Hi Trustin,
>>
>> I've found a bug in the slice implementation when start is not at 0.
>> So I correct this and add a last line in the testDiscardReadBytes method
>> of
>> the Junit test (in Aggregate since it override the default one from
>> Abstract
>> Junit test since this original test could be buggy for the test of not
>> equality of extra bytes as I wrote in previous mail).
>>
>> Here are the two files:
>> http://n2.nabble.com/file/n3613619/AggregateChannelBuffer.java
>> AggregateChannelBuffer.java
>> http://n2.nabble.com/file/n3613619/AggregateChannelBufferTest.java
>> AggregateChannelBufferTest.java
>>
>> Cheers,
>> Frederic
>>
>>
>> Frederic Bregier wrote:
>>>
>>> Hi Trustin,
>>>
>>> Ok I write and test the slice functionality (using Junit).
>>> It seems OK.
>>>
>>> I still feel like writeBytes should be left as the default
>>> implementation
>>> (ie the one from AbstractChannelBuffer) since the setBytes method should
>>> do the trick as usual.
>>> I test by using the default implementation, and all tests pass too...
>>> So, except if you think that writing by slice from source could be
>>> useful
>>> (if the source is an aggregate one), I think this method could be
>>> removed
>>> from Aggregate (so not implementing in the modified version of Component
>>> if ok) so letting the default one be called.
>>> I put a comment on this method.
>>>
>>> Cheers,
>>> Frederic
>>>
>>>  http://n2.nabble.com/file/n3565134/AggregateChannelBuffer.java
>>> AggregateChannelBuffer.java
>>>  http://n2.nabble.com/file/n3565134/AggregateChannelBufferTest.java
>>> AggregateChannelBufferTest.java
>>>
>>>
>>
>>
>> -----
>> Hardware/Software Architect
>> --
>> View this message in context:
>> http://n2.nabble.com/New-ChannelBuffer-type-proposed-tp3496606p3613619.html
>> Sent from the Netty Developer Group mailing list archive at Nabble.com.
>> _______________________________________________
>> netty-dev mailing list
>> netty-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-dev
>>
> 
> _______________________________________________
> netty-dev mailing list
> netty-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-dev
> 
> 


-----
Hardware/Software Architect
-- 
View this message in context: http://n2.nabble.com/New-ChannelBuffer-type-proposed-tp3496606p3710508.html
Sent from the Netty Developer Group mailing list archive at Nabble.com.