Re: Status of the nndb backend

[joe.hildebrand@twcable.com]

>>>>> Kees de Bruin writes:

  KdB> Hello, I followed the discussion about the nndb backend, but 
  KdB> recently nothing has been said about it anymore. Is it still 
  KdB> under development, can it already be used, or what?

The reason you haven't seen anything is that both Dave Blacka and myself
moved to new jobs a few months ago.  My new job uses cc:Mail (which really,
truly sucks rocks) on Windows (I have a windows box just to read mail.  cost
effective, no?), so I wasn't able to do any of my own mail processing.
Dave is now at Network Solutions, doing rwhois development, so he has a lot
less time than he did.

I am moving to a new, new, job next week.  Perhaps there I'll have the
infrastructure in place to do more work on nndb.

0.14 should be usable; both Dave and I were using it as our primary mail
spooling tool.  We had both stopped using procmail, even.

  Kai> I wish I had time to do any work on it.  Back when I had time, I 
  Kai> tried to run nndb which dumped core while indexing messages.  As 
  Kai> I know next to nothing about Perl I was unable to find the 
  Kai> error.

I don't think we were ever able to reproduce this.  Perhaps it was a low
memory or disk space condition?  I was able to index several thousand articles 
without a problem, but I had a Sparc20, with about 8G of disk and ~128M of
main memory.

  Kai> I have tried to use nndb-0.14 and to issue the UPDATE command, 
  Kai> which updated a few groups then barfed.  This is with the 
  Kai> Berkeley DB backend on Perl 5.002.  Has anybody got this 
  Kai> working?  Maybe I just ought to try gdbm?

I think we decided that the Berkeley DBs were too big, and changed the default
to gdbm.  But I don't remember.  Do you, Dave?  We did a bunch of performance
tests (for a work-related project) on the relative sizes and speeds of gdbm
vs. berkeley.  I remember the verdict being that the gdbm databases were 
smaller, and faster as long as you weren't accessing them via NFS.  Over NFS,
gdbm was *dog* slow.  Like 8-10 times as slow.  So if you use gdbm, put your
databases on a local disk.

Despite all of that, I would suggest mostly using the defaults, if you can,
since that is the most tested case.