On Mon, Dec 15, 2003 at 03:00:19PM -0800, Justin Mason wrote: > > There's definitely a lot of odd stuff in the SQL code, and we need > someone who would be willing to take it over and add the new things > we need (like known-good ordering of user/GLOBAL/@GLOBAL blocks, > and Bayes/AWL-in-SQL integration). Unfortunately none of the core > team are using it. > > Any volunteers? >
Agreed, I'd like to see some sort of common interface (obviously via DBI) that would make user level databases easy to setup under whatever you choose. I've got it working quite well for AWL and have it going for Bayes but haven't managed to get it into production yet (mostly time constraints and vacation). The bayes stuff involved a fairly radical change to BayesStore that may or may not go over well. See http://bugzilla.spamassassin.org/show_bug.cgi?id=195 I'd love to see some sort of more generalized SQL interface that can be used by many different "subsystems" can use for their data storage. For instance, the hashcash stuff Justin just added. It uses a DB_File to store the double spend data. It would have been great if he could have made some sort of API call to store the data, hiding the storage details. With the addition of the AWL and Bayes SQL storage backends there would be three similar but slightly different methods for talking to a SQL database, I'm gonna try and unify at least the AWL and Bayes SQL stuffs as time permits. Admittedly I don't have a whole lot of experience with the SQLConf stuff. I've only set it up once for a short while and haven't really messed with it much since. One thing I've been really contemplating with the bayes stuff I did. As written the code attempts to support as many sane[1] database backends as possible. This means you have to make some compromises. I also wrote a MySQL optimized version of the code and should the generic code get comitted I'll probably release the optimized code to CPAN as a sort of addon. What would really be helpful is some sort of plugin aware config system that would allow external modules to have their own set of config directives without having to make Mail::SpamAssassin::Conf aware of them. I think Malte was going to do some work on this at some point. As far as a volunteer, I'm more than willing, it's certainly an itch I'd like to scratch. Michael [1] By sane I mean something you'd actually put to use in this sort of situation, for instance MySQL, PostgreSQL, Oracle, DB2, maybe SQLite. Not DBD::CSV or something similar which would have no advantage over DBM. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
