#34 Select db backend at runtime

[Georg Sauthoff]

As-is, one has to select a db backend like bdb/sqlite/lmdb at compile time. This is a bit unfortunate for packaging bogofilter, as the packager either decides to just support the default backend or to create a separate package for each backend. As a user who installs bogofilter via the distribution's package manager a suboptimal situation.

Looking at the code, adding some kind of runtime dispatch shouldn't be a big deal.

Is this something the bogofilter team would be interested in?

[Matthias Andree]

I wonder what the concept would look like, and if we went that way, if we could replace one layer of indirection with a new one, rather than adding one in between...

[Georg Sauthoff]

I would implement it like this:

• compile the different backends as shared objects
• depending on the configuration load the default/specified backend with dlopen

Then declare the backend API functions as weak in the executables such that they can be directly called - i.e. after the dlopen. This also allows for linking the binaries without the definitions of those functions being available.

A more conservative appraoch (for platforms without weak symbols):

• have some global struct with function pointers which point into the loaded backend (i.e. has to be initialized after the dlopen)
• all code that interacts with the backend has to go through these function pointers - either directly or with a set of helper functions (which just forward their arguments to the dereferenced function pointers)

I don't know if there are interesting platforms with shared libraries but without weak symbols. Probably not.