-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Quinlan writes:
> Theo Van Dinter <[EMAIL PROTECTED]> writes:
> > Since we've already overloaded the add_facilities() function to also
> > change level w/ "info", we could change it so that one can override
> > for all the levels.  That would make it easier for people to just keep
> > using "-D", but it does overload the facility API.
> 
> If I supported lowering/raising more so, I'd add a new API.

I'd say the easiest way to do it would be to add a new "-v" (verbose)
switch -- either than or turn info into something that's logged by default
unless the user uses a new "-q" (quiet) switch. Those are the generic
UIs generally used in UNIX utilities for this.

I'm not fond of the "-Dinfo" special case.  It reminds me too much of
the frankly bizarre "-Drbl=-255" incantation.

I know you don't like adding new switches, but adding a *special case* to
an existing switch, which takes an entirely different action, is in my
opinion even *more* confusing for users.


> > It seems like the breakdown ought to be something like:
> > 
> > dbg         messages only seen with -D, nothing major
> > info        messages only seen in logs (not STDERR), nothing major
> > warning     messages logged and seen via STDERR, but processing continues 
> > (warn)
> > error       messages logged and seen via STDERR, processing stops (die)
> 
> I can change the code to set different levels per facility.  That's not
> too hard.  I'll try to check in a fix this weekend.

What does this mean?  I don't understand what "different levels per
facility" refers to.


> The other possible addition would be to add a notice() level for most
> log-centric messages in the spamd and preforking code.

I like Theo's definition table above, a lot.  Could we add that to the POD
as a guideline?  ...And where would notice fit in?

> > FWIW: I've already had users complaining to me about the info output.
> > They'll run sa-learn, see some info output saying that a config line
> > can't be parsed, and think sa-learn failed.  So the new verboseness is
> > going to cause issues.
> 
> Well, they are errors!  Most Unix programs would show an error.

Yes, I think it's acceptable for a command run manually.   We need
only be silent for the filtering case (ie the "spamassassin" cmd).

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFChnuWMJF5cimLx9ARAvw+AJoC95JCF94GX+HPirLa3hneIr4i/gCeLio3
cnbFskqZsOo3zAnCTgn6BdE=
=C6Xi
-----END PGP SIGNATURE-----

Reply via email to