Work on the abstraction layer for the storage backend continues. 
  
 There is a new directory ./server/backends/ that is similar in design to
./server/modules/ for the rest of the server modules.  I chose to open a 
different
hierarchy because, as previously mentioned, the storage backend gets initialized
long before the add-on modules get initialized. 
  
 There is a file ./server/database.c which handles the selection and activation
of one of the available backends.  Naturally, it is simply hardcoded to activate
the Berkeley DB backend right now, because that's the only one we have. 
  
 If you want to write a backend, here's what you have to do: 
  
 1. Create a directory ./server/backends/foo 
 2. Populate it with ./server/backends/foo/foo.c and ./server/backends/foo/foo.h

 3. Modify ./server/database.c to include your header file, and to call your
initialization function instead
of the BDB one. 
 4. Implement the interface described in ./server/database.h, using 
./server/backends/berkeley_db/berkeley_db.c
as a reference. 
  
 Since this is a brand new effort, I cannot guarantee that the interface won't
change a bit as we refine the abstractions.  But it won't change much; the
basic functions are pretty much in the form they'll continue to be. 
  
 My next task is to update `ctdldump` and `ctdlload` to use this interface
instead of calling BDB directly. 
 

Reply via email to