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