<snip> > > I'm continuing to develop MINA based protocol handlers. In fact, the > > project is moving to safehaus.org and is really gaining momentum. I > > think the MINA architecture would serve JAMES well as much of the talk > > regarding fast-fail overlaps work already done in MINA itself. > > If you want to contribue to JAMES, which I believe is the mutual desire, > doing development elsewhere just makes it a longer road to get into our > codebase.
Here is my reasoning for developing a MINA based SMTP framework at Safehaus. What I really need is a lightweight, embeddable SMTP server. I don't need a full email server (at least, not yet.) I just need to be able to receive SMTP messages and process them. I also wanted to learn how to use MINA. In the process, a lot of people have expressed similar desires for either a lightweight SMTP server or a MINA based SMTP server. Working at Safehaus helps us to accomplish these goals. Certainly I would like my code to be used in JAMES but it would take a lot of effort to rewire everything. Also, considering the fact that any TLS over NIO would require J2SE 5 (or a custom SSL engine which would be a waste of time IMO) I'm not sure how MINA and JAMES fit together right now. When JAMES is ready to move to J2SE 5, I would be more than happy to help in the migration to MINA if that's what JAMES really wants to do. > As for MINA, I agree with the approach to use a NIO-based framework, and I > like what we're doing with MINA, but I believe that it would be a mistake to > tie our fast-fail to MINA. It isn't necessary as far as I can see, and I > believe that Trustin concurs. As far as I can see, all we need from MINA is > RFC compliant handling to deliver properly terminated lines, which we'll > take from there. Please forgive me if I'm mistaken but I get the strong impression that you don't really understand what MINA is all about. If all you want is "RFC compliant handling to deliver properly terminated lines" over NIO than MINA provides much more than what you want. Danny has talked a lot about providing a SMTP command chain for fast fail. (This is, of course, a great simplification of what Danny has proposed.) MINA provides a protocol filter chain out of the box. If you look through my code, you will see that I use this as part of my STARTTLS implementation. If the "TLS is required" option is set, I have a MINA protocol filter that checks to see if TLS is enabled and if it iss not, it only let the STARTTLS, EHLO, NOOP and QUIT commands through per RFC 1854. Danny also stated very clearly in an email he sent May 13 that: "Fast fail is, by definition, a protocol handling issue. We consider fast fail to be the termination of the protocol session with an error and a message before the message has been received." MINA is a protocol framework. It's NOT just a NIO framework. Trustin is working on providing regular socket support in MINA. There is also work for providing RFC232 support in MINA. MINA is a protocol framework. It greatly simplifies the process of writing protocol handlers. So, I'm going to have to call BS on Trustin concurring that MINA not be used to provide fast-fail. I doubt he would implement such a flexible protocol framework and then tell people not to use it. -Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
