option proliferation

[David Relson]

At 01:38 PM 8/1/03, Matthias Andree wrote:
>David Relson <relson at osagesoftware.com> writes:
>
> > The three input formats - mailbox, maildir, and message count - are all
> > useful, each in its own way.  Output formatting, while not absolutely
> > necessary, helps make the results useful for the many environments the
> > program is used in.
>
>I don't dispute the necessity of reading several input formats, what I
>dislike is that the format is buried deep inside the lexer.
>
>What if we had modules like mbox.c maildir.c bulkreader.c that could
>each split their respective input into individual mails, call the
>"libbogofilter.so" functions to do the lexer and evaluation work?

That _would_ be an improvement.  Go for it!

> > exitcodes are useful to scripts that run bogofilter and have access to
> > the codes.  Bogofilter's output also needs to be text based so MUA's and
> > filters can use the information.
>
>What filters are in wide-spread use that cannot parse either the
>passthrough output or the terse output format (if we hardcoded the
>latter, that is)?

Even with simple terse mode, there are differences of opinion and 
usage.  For example, I like tags S/H/U and Greg likes 1/0/?.  Both work 
with the standard terse format "%1.1c %0.6f".  Bogotune uses format "%0.16f".

> > A sysadmin decides how he/she wants bogofilter to work in his/her
> > environment.  The supporting scripts are changed to fit those decisions.
> > Once setup, the environment is quite stable and unchanging.  There's no
> > need for many "if"s to support possibly different options, because an
> > environment doesn't use many different options.
>
>Still, we just introduced another of these "if"s, "if bogofilter < 0.14,
>exit code 2 means... else if newer, exit code 2 means...".

True.  There are "if"s in bogofilter's code - lots of them.  I thought you 
were referring to "if"s in scripts.

> > As I use the term "exit codes" it refers to the value passed to exit().
> > The codes _used_ to be 0,1,2 and have been changed to 0,1,2,3.  They are
> > not user changeable (except by editing the source code and
> > rebuilding).
>
>Yup, with 2 changing meaning as far as I read NEWS.

Yes, it did.  As already mentioned I'm willing to let error status have 2 
and to assign 3 to unsure.  Other users need to let us know what _they_ want.

> > "Y/N/?", "S/H/U", and "1/0/?" are alphabetic spamicity tags and can be
> > changed by a config file option.
>
>Not useful IMO.
>
> > Doing as you suggest _would_ definitely simplify matters.  Go for it.
>
>OK.
>
> > Would you care to take on designing the new API?
>
>I'll take a sheet of paper first though.
>
> > If people want them changed, I'm willing to swap error and unsure.  The
> > particular values don't really matter, though I like having error as the
> > biggest.
>
>The problem is that we still don't have room for extensions then. As the
>next code is desired for some condition, we start shifting the error
>code again. One might consider using 99(*) for error, drop 2 and use 3
>for unsure. It's just as ugly, because it still involves changing
>existing stuff. I'd vote to leave 0, 1, 2 unchanged (modulo -p -e
>effects) and add new options behind. It may look ugly, with the error
>code being buried in the middle, but that's how it has come to be...

It was suggested that the code be changed from 0,1,2 to 0,1,2,3.  The list 
was queried and all votes (except one) were in favor of the change.  It can 
be changed again, if people want.  0,1,3,99 would be fine.