>> >> 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.
Does it impact performance? > 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 ...) Netty is a bit different here, it hides the object inside ChannelEvent. Just had a brief look at the framework :-) Should we ask this in user ML, and try to see what our users would look out for in Codec Repository? - ashish
