simplicity vs safety with complexity

[David Relson]

On 25 Jan 2005 07:35:42 -0500
Tom Anderson wrote:

> On Mon, 2005-01-24 at 19:49, David Relson wrote:
> > I've got a question for y'all.  Would you rather have 
> > 
> > 1) a wordlist that's simple, easy to backup, but vulnerable to software
> > and hardware crashes; or
> > 
> > 2) a wordlist that offers crash protection but is complex to maintain,
> > backup, ... 
> 
> I pick:
> 
> 3) a wordlist that's simple, easy to backup, and offers crash protection
> 
> Let's work on that.  For now, I'm still using 0.92.8, and it works
> great.  I don't have the time or energy right now to battle with the
> problems others are having with transactions.  Could we perhaps try a
> different database?  All of my linux systems have MySQL installed... how
> about that?  It would fit in great with typical LAMP environments.  Or
> maybe Postgre?  Or how about using a running backup where two identical
> wordlists are synchronized, a change is made to one, db_verify is run on
> it, and if it doesn't verify, resync with the backup, else bring the
> backup up to date?

...[snip]...

> Well, part of the problem is that we've been spoiled with the simple,
> easy, vulnerable version.  We want the transaction version to be just as
> simple.  If 1.0 launched with transactions as default, new users would
> come on board having no other experience, and may just pick it up
> quickly.  Or they may give up, uninstall, and bash us on blogs.

Hi Tom,

As you know we (mostly Matthias) are working on that.  Bogofilter with
transactions has come a long way since 0.93.0 was released in November.
It hasn't yet reached the ideal of quick, simple, and safe.  If 'twere
easy, the task would be finished :-) 'Tis possible that we can't achieve
all three with BerkeleyDB.  In fact, I'm not aware of database
alternatives that provide them all.

I agree that we've been spoiled!  Clearly many people have learned to
deal with bogofilter's particular needs, although I suspect that some
folks have thrown in the towel because it's already too complex --
calling for understanding of MTA, MDA, MUA, etc, etc.   Adding Berkeley
DB transactions to the learning curve may be too much, or it may not be.
That "may be" is what lead to a "phasing in of complexity", also stated
as "non-transactions for newbies; transactions for the pros".

Regards,

David