Decoders

[César Fernando Henriques]

Hi,

On Fri, Jun 12, 2009 at 3:04 PM, "이희승 (Trustin Lee)"<trustin at gmail.com> wrote:
> 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.

I will check it and I will let you know once I get some work done.

Thanks,
Cesar.-

>
> Thanks,
> Trustin
> --
> — Trustin Lee, http://gleamynode.net/
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
>