[Repost] New ChannelBuffer type proposed

[Trustin Lee (이희승)]

Hi Frederic,

On Fri, Sep 25, 2009 at 2:14 PM, Frederic Bregier <fredbregier at free.fr> wrote:
>
> 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 ?

Sure.  Sounds great!

> I could also directly patch on trunk but if you don't mind, I would prefer
> you check a last time before comiting, ok ?

Let's create a new temporary branch.  I still need to maintain 3.1.x
branch and this feature should go to 3.2.  WDYT?

Thanks!

— Trustin Lee, http://gleamynode.net/

>
> 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.
>
> _______________________________________________
> netty-dev mailing list
> netty-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-dev
>