[Repost] New ChannelBuffer type proposed

[Frederic Bregier]

Hi Trustin,

Ok with the new branch.
I will create it named "aggregate" in order to know for what reason it is
there, if you're ok.

Cheers,
Frederic


Trustin Lee wrote:
> 
> 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
>>
> 
> _______________________________________________
> 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-tp3496606p3711065.html
Sent from the Netty Developer Group mailing list archive at Nabble.com.