Berkeley DB, was Telecom & Mnesia - Call Detail Record Collection

[Scott Lystig Fritchie]

>>>>> "dp" == phillipd  <phillipd@REDACTED> writes:

dp> It would seem to me that segmenting transactions to Berkeley DB
dp> that has several "instances" running on the various nodes would
dp> work. [...]

Speaking of Berkeley DB...

... In a former life, I had a fair bit of experience dealing with
Berkeley DB and it's no-longer-shiny-new transaction mechanisms.  One
project (rough prototype) was a user-space file system that
intercepted all file I/O system calls and stores the "files" in DB
tables.  The other (which worked surprisingly well) involved writing a
wrapper API that looked like a (large) subset of the Berkeley DB API
but stored the data in an external ODBC data store instead.

Both of those projects have been set aside since that former life
became the former life.  But I've always been tempted, just for fun,
to write an Erlang driver for Berkeley DB.  The itch to hack on a
hobby project is strong right now.  :-)

The other itch I've got is to write a driver for Spread, a reliable
multicast toolkit.  (See http://www.spread.org/ for details.)  The
database possibilities of Spread + Mnesia or of Berkeley DB + Mnesia
or of Berkeley DB + Mnesia + Spread are quite interesting.  After all,
Spread is already being used with PostgreSQL to build the PostgreSQL,
Inc. Replication Server (called eRServer?)....

If anyone has any ideas on how I ought to be procrastinating working
on home remodelling projects, contact me with your opinion.  :-)  I
can't make any promises about if/when I'd get anything done, but
sometimes a person has just got to hack.

-Scott