option proliferation

[Matthias Andree]

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?

> 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)?

> 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...".

> 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.

> "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...


*) 127 and 126 are used by shells (not found, not executable or
   something), and we should leave some room below. 128 is used by most
   systems as a bit flag for a "core dumped" condition, so the useful
   range is at most 0 - 125.

-- 
Matthias Andree