Hi Greg, On 2/3/07, Greg Duffy <[EMAIL PROTECTED]> wrote:
Hi MINA crew! I have a couple of questions about the current datagram transport implementation. I'm using the svn trunk directly (2.0.0-M1-SNAPSHOT). Is there a reason that DatagramAcceptor and DatagramConnector use a delegate pattern? Also, is there a reason that they can't have multiple processor threads like their socket counterparts?
I used delegate pattern to hide DatagramService (in datagam.support package) interface which provides public internal methods (e.g. flushSession). It would be better if there's a way that doesn't use a delegate pattern. As you know, datagram transport doesn't have more popularity than socket transport. That's why we didn't implement multiple processor threads yet. We've been focusing on socket transport. There's no other reason, and datagram transport needs improvement definitely. I don't know if there is an architectural difficulty I'm missing, or if
there hasn't been enough dev time/interest to spruce up the datagram implementation, or maybe something completely different. If it's just the lack of dev interest or time, I might be able to make a patch for it. I've done one other MINA patch for the IoSessionRecycler, so I've at least gotten my feet a little wet in terms of contributing. (and I even know now not to accidentally hit my Eclipse format shortcut before submitting my patch!)
Your patch is always welcome! It is always great to have someone who deals with various transport types. Julien is working on serial / parallel port support, and you could lend us your hands to improve our datagram support. :) What do you think? Are there any gotchas that I don't see? You didn't misunderstand anything. I am impressed! Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
