Darrell, > It won't be quite the same. The other protocols work by reading one line > at a > time and passing this to a command-specific method, where it is parsed, > optionally logged, etc. IMAP uses a parser-style approach, where the line > is > never read in it's entirety. This is important, because IMAP commands > often > can span multiple lines (eg when "literal" strings are used). Rather than > log > the raw command, I think I'll construct a log message consisting of the > command name and parsed parameter values.
It's actually almost exactly the same. I can say this with some authority because I've done most of it. :) It's in the revision of IMAP that I've got sitting on my box. I will, as I mentioned before, be checking it in shortly after 2.1 is out the door. I, like all the other committers working on 2.1, deferred further work on 3.0 until after 2.1 is out the door. I'm well aware of the literal issue - you may notice that I mentioned it you in my earlier message to you regarding IMAP. It's one of the big problems with the previous revision. IMO, it needs to be fixed using a builder pattern, not a parser. A parser is essentially object-level state unaware, while a builder is state-smart. As far as logging only after parsing, I'd actually reconsider. Part of the reason you want to get the raw input as your starting point to your process. Logging only after parsing/building will of course hide errors in your parser/builder. It is common to log something approaching the raw data (with appropriate filters for secure/overlong data) and then have abbreviated log entries to describe the post-parse/build. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
