exit codes in docs

[Matthias Andree]

Greg Louis <glouis at dynamicro.on.ca> writes:

>> It boggles my mind that people are using exit codes at all for what is
>> clearly program output.
>> 
> One objective of bogofilter is to scale well.  Parsing ASCII output
> takes a good bit more time than checking return codes.

We may have scalability concerns, but converting a single string per
mail to a double certainly is not relevant to scalability.

What is way more important than scalability is having stable
interfaces. That's what people build on, if they must change their whole
integration stuff with every point release of bogofilter, they'll switch
software when they're fed up.

It's not the addition of an exit code for "unsure" that bothers me, but
the change of an interface. We absolutely need a stable interface before
we release bogofilter-1.0. If we want an extensible interface, then the
exit code interface doesn't look too attractive.

I'll reiterate my procmail example criticism again:

many of the procmail examples, namely of the

       :0HB:
       * ? bogofilter
       Mail/spam

kind, mix all possible results, error, unsure, nospam, into one
set. This is wrong. It's not robust, it's not support-friendly and not
the right thing to do. We shouldn't encourage such false use.

We should remove that example; unless there is protest within 24 hours,
I'll remove it.

Then, we should define a machine-readable, extensible interface that
prints a single line per mail on stdout and that a user cannot
redefine. Casting bogofilter -tv with built-in defaults into concrete
comes to mind. We can offer a configurable interface with a separate
option, but I want to have a "canonical interface" that is configuration
invariant and that people use in problem reporting and that should be
the preferred way of using bogofilter results in a script.

-- 
Matthias Andree