Le Tue, 31 Mar 2009 09:44:27 +0200, Emmanuel Lecharny <[email protected]> a écrit :
> Ashish wrote: > > After the wonderful discussion yesterday, went back and had a quick > > look at the codec that I intended to design. > > > Cool ! > > Here is what I needed to replace existing blocking IO > > 1. POJO's - The High level representation of a protocol (already > > there) 2. Decoders - How I collect information from lower layer eg. > > CumulativeProtocolDecoder..etc and convert them to POJO > > 3. Encoder's - How to convert POJO to byte array > > > I would add a ProtocolCodecFactory for stateful codecs. > > For us, the tricky part is POJO's. There are two questions > > 1. Do we maintain protocol POJO's? > > 2. Do we use an 3rd party POJO library (in my case its jsmpp) > > > The POJO issue is a big one. Usually, when one writes an application > based on a protocol, he uses his own POJOs (for many reasons). The > codec POJOs should be specific. Last, not least, you may need to > write a converter. > > We ave done that in LDAP, we have two different POJOs, one for the > codec, another one we use in the server, and a converter. > > Maybe a good idea would be to tell the users to add a ConverterFilter > after the codec filter in order to do this transformation. Of course, > this is not possible in the current implementation, because filters > just manipulate IoBuffer (what a pain ...) I often use a 2 stage strategy for Text line based protocol. A TextLineCodec for transforming BB into String and an Iofilter for transforming String into POJOs. So I see no problem to have a ConverterFilter after the Codec for transforming POJOs. Julien
signature.asc
Description: PGP signature
