"D. J. Bernstein" <[EMAIL PROTECTED]> writes:
| Scott Schwartz writes:
| > solution for this problem.
|
| What problem?
The one we've been discussing? I realize that you don't perceive it as
a problem; that's obvious from the fact that you don't log any smtp
activity at all.
I'd respect your opinion a lot more if you actually used recordio in
the mode that you advocate for purposes of argument.
You don't use recordio for routine logging; that proves that recordio
is the wrong tool for the job, not that routine logging is a bad idea.
| What exactly do you want to see in the log?
All the things we've sent you patches for.
| How many times do I have to ask this question before you answer it?
I've already explained what I want, if you'll recall. It's obvious
that this isn't the question you really have in mind. You want to know
if there is internal state in smtpd that cannot be deduced from
watching all of it's I/O. If there is none, you will declare recordio
a success and disregard the valid objections to it's use.
I'm not sure that I agree that there is no hidden internal state, but
for the purpose of argument, consider it stipulated. Nonetheless,
recordio is wrong: The requirement you are ignoring is the need to
*not record* and to *not deduce*.
I have no desire to parse recordio's encoding of smtp just to discover
discover if any interesting events have occured. Rather, smtpd (which
has already done all the necessary parsing) should be quiet (recording
only the queue id) unless it has an error to report, in which case it
should report only that.
recordio is a useful debugging too, like tcpdump, or NFR,
but it's not the right design for routine logging.
