http://bugzilla.spamassassin.org/show_bug.cgi?id=3701
------- Additional Comments From [EMAIL PROTECTED] 2004-08-18 20:02 ------- for reference -- here's the IRC log of our thinking on this: <quinlan> it should just be dbg(facility, severity, "message") <quinlan> dbg(DNS, WARN, "spamcop timed out") <jmason23> yeah, but then you get into the situation where you've got hundreds of facilities -- and nobody can remember which is which (cf sendmail) <quinlan> dbg(DNS, ERROR, "spamcop returned SERVFAIL") <quinlan> hundreds? god I hope not <quinlan> I'd just have two levels: warn and error <jmason23> and you get option explosion on the command line (although we now already have that with the current -Ddns=-255 wierdness) <Dip-> Did the configuration parameters for Subject rewriting change between the 2.6 and the 3.0 branch? <jmason23> quinlan: talking about facilities, not levels <jmason23> @faq <sabot> faq is http://wiki.apache.org/spamassassin/FrequentlyAskedQuestions <quinlan> jmason23: I know, but do you agree re: two levels? <quinlan> I guess we could have 3 or 4: maybe also an info and a fatal severity <jmason23> quinlan: not sure. the ERROR level should be just warn(...) <quinlan> I don't really like the mix-up we have between die/warn/dbg <jmason23> what d'you not like? <quinlan> stderr should only be used if we're not using syslog <quinlan> but everything should be going to syslog OR stderr, period <jmason23> quinlan: in perl, warn() is very easy to rebind. that's important <jmason23> ditto die() <quinlan> can we add args to warn and die? <quinlan> warn(facility, message) ? <jmason23> hmm. do you mean facility, or level? <felicity> dip-, yes. see the docs. <jmason23> need an example here <quinlan> facility==service==module==area (roughly) <quinlan> severity is the severity of the message <jmason23> ok. I'd suggest we adopt a loose convention -- pretty much the one that's already in a lot of the code <quinlan> "facility: message" ? <jmason23> namely, warns/dies/dbgs for a specific facility are "facility: message" <jmason23> yep! ;) <quinlan> we mix up between warn/dbg a lot <quinlan> it's not clear which to use when <jmason23> yeah. in general, we should be warn()'ing for errors that aren't automatically recovered from <quinlan> aren't ? <jmason23> yeah. errors that really are errors ;) <jmason23> dbg() for the ones we can recover from <jmason23> such as autolearning not being able to get a lock etc. <quinlan> maybe we should use levels (what syslog calls what I've been calling severities) as defined by syslog? <quinlan> EMERG, ALERT, CRIT, ERR, WARNING, NOTICE, INFO, DEBUG <quinlan> I don't quite like that, but we could do something similar or a subset <quinlan> and then we should remap warn/die to use syslog <jmason23> quinlan: we already do remap warn/die in spamd <quinlan> when syslog is used... <quinlan> ok, good <quinlan> then we need to be more consistent with the convention <quinlan> maybe define two things above warn() (meaning less important) <jmason23> I'm not sure what problem you want to solve here with severities btw ;) <quinlan> um <quinlan> if you turn on debugging, it's TOO much <jmason23> ok, that's a good argument for facilities <quinlan> I'd say, any warning/die goes through, obviously <jmason23> yep, as it does in the nondebug case <quinlan> dbg("facility: foo") is also good for debugging-level information <quinlan> we might want to add a info() which is something normal, but significant <quinlan> like: a DNSBL timing out <jmason23> dbg ("facility: foo") sounds like the way to do it IMO <jmason23> and then have a mode of -D that'll only show debugs from the named facilities <quinlan> -D:dns or whatever <jmason23> info() -- hmm, good point... but would that be mapped to warn() or what? <quinlan> it would map to warn, but would be ignored unless you turned on info-level for everything or that facility <jmason23> and info-level wouldn't be the default <quinlan> definitely not <jmason23> I suppose that'd be like a "verbose switch"; a -v would turn on info <quinlan> we might wannt to look at what bind and other network servers do here <quinlan> bbias * jmason23 tries to think of a daemon with decent logging <felicity> I don't want us to get complex enough where you need to configure logging in a file somewhere. <jmason23> we're quite different, anyway, from most of those -- in that our code is both a library and a network server <felicity> actually I could have stopped at "logging". <quinlan> back <quinlan> maybe we should just fix dbg first <quinlan> a possible plan for fixing dbg: <quinlan> -D means all debugging is on <quinlan> -D=fac1,fac2 means debugging is turned on for those <quinlan> just an array stored in Conf <quinlan> or wherever <quinlan> dbg("string") is only printed if /^([^:]+)/ is listed in that array (or "all") <quinlan> so you'd better use a facility unless you only want to be printed for "all" <jmason23> yeah, sounds sensible enough to me <jmason23> theo? <quinlan> and all warnings and dies should use the same list of facilities <quinlan> should, not must <quinlan> this obviously gets rid of the -1,-2 whatever crap <jmason23> good news! <quinlan> info() might still be useful - stuff less than a warn but more than a dbg <quinlan> we can decide once dbg is done I quite like the idea (so far ;) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
