Decoders

[César Fernando Henriques]

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.

Thanks

Cesar

>
> HTH,
> Trustin
>
> -----
> Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> View this message in context: http://n2.nabble.com/Decoders-tp2954094p3004409.html
> Sent from the Netty User Group mailing list archive at Nabble.com.
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>