Pipeline design issue

[djunforgetable]

Hi there,

I had more of a design issue around Netty.  I'm attempting to write some
server side stuff for AMQP to see if it'll run faster than MINA for Qpid. 
Right now the upstream is

Socket -> MyFrameDecoder -> NettyHandler (delegate) -> MyHandler

The NettyHandler just accepts a delegate.  I do this mainly to abstract
Netty from the core of the code.  As such, the MyFrameDecoder also accepts a
delegating decoder that is abstracted away from netty libs as well (it
accepts a buffer interface, not the channel buffer).  

For those familiar with the protocol, the first frame received is the
protocol version, the remainder are frames encoded with that version.  This
means, my MyHandler and my MyFrameDecoder need a handle to the same instance
of the decoder to set the protocol version it needs to deal with.  Does it
make sense to do it this way?  Is there a better way? I don't want to fiddle
around with the pipeline or deal with channel locals.  Can anyone else think
of something better?  
-- 
View this message in context: http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Pipeline-design-issue-tp5901781p5901781.html
Sent from the Netty User Group mailing list archive at Nabble.com.