My first inclination is that Serge has the right idea, but possibly the wrong solution to the problem. Having per-message logs (Msg#.log) won't scale, and I believe that problems arise other than in someone's controlled test environment as they develop their pipeline logic.
Good point.
It seems to me, and there is also a bugzilla entry that relates to this, that we should audit all of our message related log formats to make sure that the content is parsable and has all of the necessary information to associate log messages with mail messages, and then provide a log analyzer.
I may be forgetting, but I'm pretty sure this relates only to using something like webalizer to analyze sendmail-style logs, so as I put it, the SMTP-stuff.
A hypothetical pipeline analyzer could merge the various existing logs, sort them by message key, and then filter out events by the message(s) we're interested in following.
While this could help isolate an odd production bug, I think it fails for users trying to learn James and actively debug mailets or matchers.
Serge has made a point that logs for smtp traffic analysis and logs for pipeline debugging might have different content/formats. Possibly so, but I don't believe that precludes using a log analyzer.
I understand a log analyzer for smtp traffic (like webalizer). Unless you're talking about some GUI analysis of some after-the-fact logging (which I don't even like that much), I don't see much value. Sure, it's better than what we have, but that says little.
Either way, we have to go through SMTP handler, the pipeline, into matchers and mailets (at least in my opinion), and the POP3 handler, and make some logging changes. At the minimum, it would seem to me that want to log
This mailet & matcher log changes... I was just talking of adding the message info in the logs. Adding message info in the logs is doable without touching the implementations, and in all but lifecycle situations, the log messages have a message associated with them and could in most cases benefit from that info.
This is an important point to me because it determines whether we add code in 3 places, or 18 + every custom mailet & matcher people use.
I believe that Serge's idea is that we would instrument the SMTP handler (probably also any similar message source, such as FetchMail), the spooler, and the log operation(s) in the MailetContext. We would have some redundant logging code, but hopefully could keep it to a minimum. I'm not sure how this per-message log would tie into the Avalon code, but that's TBD if we go this route.
I don't see how Avalon code relates to what we're talking about. What code is redundant?
Personally, I prefer the log analyzer approach for a few reasons:What's the benefit or objective? We already have debug/info/etc... control over level of verbosity, but it's still very difficult to track and goes beyond sending messages to different streams.
- logs for the log analyzer could be left on with some degree of verbosity
- the per-message log mechanism would rapidly create
too many directory entries for many platforms.
- no redundant codeWhat is redundant? You seem to be critiquing the way you would implement this...
- resolves bugzillaThis is unrelated, IMHO.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
