On Thu, 2005-04-14 at 11:11 -0400, Serge Knystautas wrote: > 1. Line feeds... it seems the protocol handler is all line feed based, so: > a. if client is sending crlf or lf, what impact does that have?
This could potentially mess things up. I'm working right now on making the protocol decoder more robust and integrating some of the cr/lf logic from James. The decoder I'm using right now was copied straight out of one of Trustin's examples. This was the simplest approach when I first started playing with Mina. > b. when we're in DATA mode, could I potentially corrupt data by > converting crlf to lf or vice versa? > c. size limit... it seems that if I sent data without a linefeed > (i.e., ababababababababababababab...), I would never complete a line and > hit the check for size limit... where is this buffer happening? Yes, data could get corrupted and the size limit checking is too simple right now. I need to move the data stream handling into the decoder and this should fix both of these issues. > 2. Command impls... I saw you inlined all the commands into the SMTP > handler class... was this just done for simplicity, and would you see > any downside to splitting each command into its own class? The benefit > would be smaller classes and more flexibility. I think this is a great idea. I in-lined all the command implementations because that's the way the James SMTP protocol handler does it. I like the idea of separating each command into its own class and making it possible to customize how each command is handled. Excellent suggestion. > 3. Configuration... I didn't look into how you configure this, but how > hard do you think it would be to take the current James SMTP > configuration and instantiate this MINA SMTP impl? I haven't really looked into this yet. I will try to look into this in detail over the weekend. > 4. TLS support... I saw an example of how MINA does SSL, but is there a > way to support SMTP's SSL feature of "upgrading" to SSL after we've > already been exchanging data with the client in plaintext? I'm not > explaining this well, but hopefully you know what I mean. I understand what you're asking and I don't know what the answer is. I will find out though. Thanks a lot Serge for your valuable feedback. -Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
