lenn...@wu-wien.ac.at wrote:
> Dear all,
> 
> I have been reading up on the discussions on this list as well as the
> concerns about databases in the FAQ. Whilst I concur with most of the
> points wrt. to a fully fledged SQL database, I think that CDBs are
> ideally suited for the purposes of spamdyke. Sam states in the FAQ
> that speed, memory, concurrency, portability and availability are not
> a concern with CDBs and I agree, especially on the speed issue. After
> all, that was what the hash file format was designed for. 
> 
> That leaves accessibility and safety for CDBs. It is true that the
> database itself is in binary form (that is where the speed comes
> from), which means that they cannot be easily viewed and checked for
> errors. At the same time, they are read only and are usually generated
> from a plain text file as input. There is no reason to not have that
> text file sitting next to the actual database file, which means we
> have all the advantages of a plain text file plus the speed benefit of
> CDBs, which can be substantial for a lot of entries. The only
> additional step required (by the admin) would be to convert the text
> file into the CDB. We could also have the best of both worlds like
> this. Suppose we have this entry in the configuration file:
> 
> recipient-blacklist-file=/etc/spamdyke/recipient-blacklist
> 
> 
> First, we look for a file with the name
> /etc/spamdyke/recipient-blacklist.cdb. If it exists, we assume it is a
> CDB version of /etc/spamdyke/recipient-blacklist and look up whatever
> we need there. If recipient-blacklist.cdb has an earlier modification
> time than recipient-blacklist (we get that for free anyway with a
> stat() on both files), we could help the admin by printing a warning
> that the CDB is probably out of date and read from recipient-blacklist
> instead. If recipient-blacklist.cdb does not exist, we use
> recipient-blacklist in ASCII format like before.
> 
> 
> Another version of this would be to have lots of new configuration
> options like:
> 
> recipient-blacklist-file-cdb=/etc/spamdyke/recipient-blacklist.cdb
> 
> That makes it possible to name the database file arbitrarily. If we
> want the safety checks like in the example above we could make it
> mandatory to name the ASCII input file for the CDB database file:
> 
> recipient-blacklist-file=/etc/spamdyke/recipient-blacklist
> recipient-blacklist-file-cdb=/etc/spamdyke/recipient-blacklist.cdb
> 
> That way all the fallbacks to ASCII plus warnings can be implemented at
> the cost of more configuration entries.
> 
> 
> What do you think?
> 

What problem specifically would this address?

-- 
-Eric 'shubes'

_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to