On 3/7/02 1:21 AM, "Matt Sergeant" <[EMAIL PROTECTED]> wrote:
> On Wed, 6 Mar 2002, Richard Sonnen wrote: > >>> >>> It's not exactly perfect, because it means we have to adjust spamd and >>> spamassassin scripts to optionally use a different Conf class, but that's >>> a trivial patch also. Want me to apply this and fix up spamd/spamassassin >>> too? >> >> This may well be the best option. (it's certainly a lower cost option >> than what I'm looking at.) Whether or not I implement my system your >> patch would certainly be useful to many people. >> >> The major advantage to a true run-time factory system is that the >> choice of conf classes can be made in a config file rather than in >> code. It could even be made based on the information available at >> request-time (much as the current SQL conf is now). > > Well I was thinking of something like: > > $opt_C ||= 'Mail::SpamAssassin::Conf'; > my $conf = $opt_C->new(...); > > In spamassassin.raw (not sure if opt_C is used yet). > > Similar stuff is possible for accessing a config file. > > (I'm aware that a factory system would be cleaner long term, but the above > is less change in the 2.x series). IANAPG (perl guru), but how does the perl -M flag work? This was the way to switch from using the default AddrList implementation to some alternate (eg perl -MMail::SpamAssassin::DirBasedAddrList spamd -xyz) -- could we not use something similar to avoid polluting the spamd/spamassassin switch-space? I'm also a big fan of Richard's suggestion to do the virtual construction through parameters in the system config file specifying the classname to use. Is it possible to do both? Referring to a statement about being able to make use of invocation-time parameters in figuring out the conf file to use, be careful about compiling any regexes at runtime; not sure if that's what you were talking about or not. C _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
