Ashish wrote:
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?
Obviously, yes. I measured it to cost around 3% more than using a single
POJO. This is a price I accept to pay because the data structre are very
different, as one is designed to speed encoding and decoding, when the
other is more specifically designed to facilitate the server's purposes.
Merging the two pojos would lead to something over complex, and probably
more costly.
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 :-)
InputStream seems just to be fine, except the Blocking aspect. Why can't
we simply define a MessageStream which is based on the InputStream
methods, but is non-blocking?
Should we ask this in user ML, and try to see what our users would
look out for in Codec Repository?
atm, I think it's better to keep it on dev. We didn't released MINA 2.0
yet, and still have to. But maybe I'm wrong...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
