[Repost] New ChannelBuffer type proposed

[Trustin Lee (이희승)]

Cool.  Let's merge it when I'm ready to move on to 3.2. :)

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



On Fri, Sep 25, 2009 at 5:18 PM, Frederic Bregier <fredbregier at free.fr> wrote:
>
> 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.
>
> _______________________________________________
> netty-dev mailing list
> netty-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-dev
>