Eric Shubert wrote:
> 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?
>
Let me field this one. The problem is that spamdyke is simply too effective to
be as simple as it appears to be - and we can't have hobby software showing up
software created by large corporations. Spamdyke lacks a certain....
enterprisiness.... It needs more grown up technologies, and sql is a good
starting point. Next, we can workout how to use xml somehow. Maybe for
configuration files!
--
Jacob Briggs
Systems Engineer
Core Technology Limited
Level 1, NZX Centre
11 Cable Street
Wellington
Phone +64 4 801 2250
--
Private Object doAnythingConceivable(String whatToDo, Object whatToDoItWith) {
.....
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
