Decoders

["이희승 (Trustin Lee)"]

César,

Sorry that I'm late.

On 2009-06-01 오후 10:16, César Fernando Henriques wrote:
> Hi,
> 
> On Mon, Jun 1, 2009 at 12:33 AM, Trustin Lee <trustin at gmail.com> wrote:
>>
>>
>> César Fernando Henriques wrote:
>>>
>>>> I thought it might be interesting if the type of HttpMessage.content is
>>>> not ChannelBuffer but Object.  Then it could make the transformation much
>>>> easier.  However, a user will always have to down-cast.
>>>
>>> I don't think It would be useful ( at least for my requirements), I'm
>>> adding more channels to abstract my application from http protocol,
>>> so my first CustomHandler will replace the HttpMessage and pass a new
>>> object to the next Channel.
>>>
>>
>> Agreed.
>>
>>
>> César Fernando Henriques wrote:
>>>
>>> Why isn't there a method to replace MessageEvent.message Object? So I
>>> can replace the message in my Channel. Rigth now  I get the
>>> DefaultHttpRequest and wrap it in a custom app object and pass to the
>>> next Channel to process application messages in a friendly way, I'
>>> doing something like this:
>>>
>>>        public void messageReceived(ChannelHandlerContext ctx, MessageEvent
>>> e)
>>>                       throws Exception {
>>>                 // detect http message type and wrap it
>>>                 ...
>>>                 // pass ti the next handler
>>>               UpstreamMessageEvent me = new UpstreamMessageEvent(ctx.getChannel(),
>>> wrappedObject,
>>>                               ctx.getChannel().getRemoteAddress());
>>>
>>>               super.messageReceived(ctx, me);
>>>       }
>>>
>>> Do you think it's viable to add a setMessage to MessageEvent so I
>>> don't have to create another UpstreamMessageEvent ?
>>>
>>
>> I prefer to keep all event types immutable.  With an immutable type, you
>> don't need to use volatile variable and there's less probability of race
>> condition.
>>
>>
>> César Fernando Henriques wrote:
>>>
>>> Another question, is there an implementation of CompressionChannel?
>>>
>>
>> There was a contribution from a user, but it was not included in the
>> official release because it was not very efficient in terms of compression
>> ratio.  Personally, I'd like to see a new implementation based of jzlib so
>> that the the PARTIAL_FLUSH method can be leveraged for higher compression
>> ratio.
> 
> OK, for sure I will need a CompressionChannel, can you point me to the
> current implementation? I will try to implement the jzlib part, let me
> know if you have something in mind to take care, so maybe it can be
> added to netty.

Here's the contribution I mentioned above:

http://www.jboss.org/netty/community.html#nabble-td1495380
http://www.jboss.org/netty/community.html#nabble-td1557053
http://www.jboss.org/netty/community.html#nabble-td1566722

MINA has a pretty good jzlib based compression filter.  You might want
to start from there.

http://svn.apache.org/viewvc/mina/trunk/filter-compression/src/main/java/org/apache/mina/filter/compression/

Perhaps it would be awesome if there is a ChannelHandler that takes the
advantages of the two implementations.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20090613/ebf99d92/attachment.bin