On Wed, Jun 11, 2003 at 08:41:16PM +0200, Kristian Koehntopp wrote:
> But the version number indicates software that might not really be mature.
> Perhaps a higher order configuration interface along the lines of
> getconfigvalue() and setconfigvalue() would be in order, which under the
> hood calls Ascii, DBI or LDAP natively?
And again I am mightily following up on my own posts.
Having actually read the documentation, I see that DBD::LDAP
tries to emulate SQLike behaviour with an LDAP backend, using a
mapping from SQL queries to emulated SQLike table within an LDAP
tree. That mapping must be created manually in a "ldb" file.
This file maps SQLike tables to flat LDAP subtrees.
This seems to me at the same time overdesigned and falling short
of what SpamAssassin would need to store configuration. I'd
rather go for the getconfigvalue() type interface I suggested
above.
Also, there seems to be a tie in within the SpamAssassin code up
until and including 2.55, where virtual-config and sql
configuration are mutually exclusive:
471 if (!$opt{'user-config'})
472 {
473 if ($opt{'sql-config'}) {
474 handle_user_sql($current_user);
475 } elsif ($opt{'virtual-config'} || $opt{'virtual-conf
475 ig-dir'}) {
476 handle_virtual_user($current_user);
477 } elsif ($opt{'setuid-with-sql'}) {
478 handle_user_setuid_with_sql($current_user);
479 $setuid_to_user = 1; #to benefit from any paranoia.
480 }
481 } else {
482 handle_user($current_user);
483 }
I have just glanced at the code, but to me it seems that there
can be no per-user bayes_journal and per-user awl if spamd is
running on sql-config.
Wouldn't it be useful to handle configuration switches
differently from journal/awl type of stuff. That is,
configuration source may be a per-user file from the users home,
per-user file from some base directory using some kind of
generator pattern, SQL or LDAP - all handles via some kind of
generically extensible interface. Journals and AWLs may come
from the users home directory or a selectable per-user file from
some base directory using some kind of generator pattern. And
finally, the common cases can be handled with some convenience
switches that provides sensible defaults for the low-level
options.
I am pretty sure that you would not want to store bayes data and
awls within an LDAP (that would create quite some load on any
replication that might be in place), and only very few people
would want to put such data into an SQL database (if they did,
the would not want to use DBM data or whatever spamassassin uses
at the moment, but use native SQL tables).
Kristian
-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
