Richard Wallace ha scritto: > Maybe some of the changes I started to make to protocol-dns could help a > bit in this area. One of my goals was to try and make the > encoders/decoders completely independent of any MINA dependencies. So > if you look at the encoders/decoders at > http://svn.apache.org/viewvc/directory/apacheds/trunk/protocol-dns/src/main/java/org/apache/directory/server/dns/protocol/ > you can see they are pretty thin wrappers around the encoders/decoders > that do the actual work which are at > http://svn.apache.org/viewvc/directory/apacheds/trunk/protocol-dns/src/main/java/org/apache/directory/server/dns/io/. > > The only MINA class that those depend on is the MINA ByteBuffer which > provides handy utility methods that are really nice to have.
About the decoder/encoder this seems to be the perfect solution. But what about MINA handler/filters ? In jSPF I introduced the concept of "continuation" so that every action can do something and return a continuation. This way I don't care of who will handle the real execution of the continuations: but now I don't know how I could port this to MINA and if this is the best approach to solve this "optional dependency" issue. I think Alex is right when he tells that a light dns library should not depend on anything but the JDK, but at the same time I think that MINA can give us many tools (e.g: spring/jmx integration, throttle filters) out of the box. Maybe MINA is more important on the server side than on the client side. >> Assuming Alex and Brian accept this, IMO a good plan could be to start >> from dnsjava+dnsjnio as this already provides full *working* synchronous >> and asynchronous resolving library. >> Then we can apply this refactorings: >> >> 1) Make the record types pluggable (currently to add a new supported >> record type you have to change core dnsjava classes) programmatically >> (we know at least 2 dnsjava forks have been started because of this >> missing extensibility). >> >> 2) Split from-the-wire / to-the-wire code from the record classes. >> 2b) Refactor the code so we can start working side-by-site on a MINA >> based protocol and on the currently working nio code (synchronous in >> dnsjava and asynchronous in dnsjnio). Maybe MINA experts can help us >> understanding how to better accomplish this without too much code >> duplication. >> > That seems like a pretty reasonable approach to me. I think much of > what is in protocol-dns can be used as a basis for these refactorings. This will take few more days/weeks to consolidate in our minds, but I really think we can find a common goal and share the effort! Thank you, Stefano
