On Mon, Dec 31, 2012 at 12:25 PM, Julien Vermillard <jvermill...@gmail.com>wrote:
> Hi, > > Since few year, I stopped to use the MINA ProtocolCodecFilter and > associated stuff (CumulativeCodec..). for implementing my own codec > independent of MINA. > :) > > it's just a service consuming ByteBuffer and pushing decoded POJO in a > callback. The point is to be independent of MINA for example, parse & save > files using the codec, or simply implement an HTTP version of the transport > using old style servlet. > Agree. The implementation need not be tied with MINA. You can expect ByteBuffer(s) and can decode. I didn't quite get the statement " or simply implement an HTTP version of the transport using old style servlet."? With this approach accumulation and decoding becomes one. We can also think about accumulating as one step and decoding as another, which may be useful for protocols which specify length or fixed headers. User provides how to find length, Framework shall accumulate bytes and once done, can pass on complete PDU for decoding. This might be an overhead in some cases. The idea is to make life easy for the framework user. Or we can provide some helper around our core Codec framework. Thoughts? > Basically a decoder looks like : https://gist.github.com/4417934 > One is instantiated by session. > Would be worth making it accumulateAndDecode() public interface Decoder<PDU> { What is PDU? It's the custom decoded POJO or an abstraction that we want to build. > > I'm quite happy with that and I think we should not port the old > ProtocolCodeFilter to MINA 3.0 and replace it with a independent MINA async > decoder framework (consuming BB, accumulating if needed and producing > pojo). > > Julien > Not sure, but do we see scenarios where we might need reference to IoSession, while decoding? Nothing comes to my mind right now, but it's year end :) -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
