A bit late back to this thread but +1 from my side since as a user I expected at least one nio library would have taken the approach that parsing(decoding/encoding) should be a separate library from actual nio frameworks. Instead it appears every library embedded/wired their parser to be too coupled with the framework :(.
The same goes for SSL as well ;). We wrote a SSL implementation that is very easy to wire into an nio framework(open source) but it knows nothing of the nio framework that uses it. (one we wrote about 7/8 years ago on sourceforge before we knew about mina/netty). We did end up having to add "Object passthrough" as a parameter in the api so the user can pass through some information which is necessary sometimes, but it still didn't need to be tightly coupled. Dean On 12/13/12 10:29 AM, "Arnaud bourree" <[email protected]> wrote: >OK, I just take a look to LdapCodec and get you point. > >Arnaud. > >2012/12/13 Emmanuel Lécharny <[email protected]>: >> Le 12/13/12 5:41 PM, Arnaud bourree a écrit : >>> I don't follow: Mina codecs process IOBuffer which is Mina specific. >>> If you want to made codec independent you should used reader/writer or >>> streams, then you loose Mina power. >> Nope. >> >> You can (shoud) disconnect the decoder completely. >> >> In fact a decoder should work with no interaction with MINA. This is >> what we have done with ApacheDS : our decoder has no knowledge about >> MINA, it's capable of decoding a LDAP request even if the data arrives >> in small chunks, and it works absolutely well with MINA. >> >> All our decoding tests are done with the decoder, and no MINA around. >> >> >> -- >> Regards, >> Cordialement, >> Emmanuel Lécharny >> www.iktek.com >>
