Something like org.apache.commons.codec.Decoder and org.apache.commons.codec.Encoder but modernized with ByteBuffer / generics. so you can only depend of this third party jar. Julien
On Mon, Jan 14, 2013 at 1:26 PM, Julien Vermillard <[email protected]>wrote: > I wasn't thinking about making MINA 2 Codfec stuff comatible with MINA 3 > ones, just wondering how we share the framework independent API. > If you want to use the codec, with.. let's say plain java.net.Socket > blocking stuff. It would be stupid to depend the whole MINA3 core ? > Julien > > > On Mon, Jan 14, 2013 at 11:06 AM, Emmanuel Lécharny > <[email protected]>wrote: > >> Le 1/14/13 10:55 AM, Julien Vermillard a écrit : >> > I started refactoring MINA 3 HTTP Codec, but I wonder how to share the >> > codec infertaces (ProtocolDecoder.class and ProtocolEncoder.class) >> between >> > MINA 3 and MINA 2 ? a separate module ? >> > Because if we don't do that we will finish by having the two version >> > depending of each other like with the current LDAP codec. >> >> The issue with MINA 2 interfaces is that it requires additional >> parameters : >> >> void decode(IoSession session, IoBuffer in, ProtocolDecoderOutput >> out) throws Exception; >> and >> void encode(IoSession session, Object message, ProtocolEncoderOutput >> out) throws Exception; >> >> The ProtocolDecoderOutput/ProtocolEncoderOutput are callbacks. >> >> I would suggest we use simpler methods : >> >> Object[] decode(IoSession session, IoBuffer in) throws Exception; >> Object encode(IoSession session, Object message) throws Exception; >> >> where the returned Object whould be the decoded messages for the decode >> method, and the encoded message for the encode method. >> >> Woudl we have more than one message being decoded, we will get an array >> of decoded messages. >> >> I do think it's way easier to use than using a callback... >> >> >> Regarding the compatibility with MINA 2, forget about it. I have >> migrated ApacheDS from MINA 1 to MINA 2 3 years ago, and despite some >> kind of attempt to make MINA 2 quite API compatible with MINA 1, it >> required a full rewrite. At some point, you'd better accept the idea to >> review your code and switch. ALl in all, it took me a couple of days, >> max. I must say that switching to MINA 3 does not frighten me *at all*. >> >> Let's not make MINA the next Windows, still assuming some kind of >> inheritence with MS/DOS 2.1... >> >> -- >> Regards, >> Cordialement, >> Emmanuel Lécharny >> www.iktek.com >> >> >
