> >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). The system I had in mind would work something like this during a normal lifecycle: SpamAssassin.pm calls ConfFactory->new() with any arguments to its own constructor and a copy of itself. ConfFactory->new() would do a path search for config files, just like SpamAssassin.pm does now. Any files that were found would be concatenated and passed to a base Conf class to be parsed. In normal operation this conf class would then be handed back to SpamAssassin.pm as normal. If, however, one of the config files contained a tag like: configClass Mail::SpamAssassin::SQLConf the factory method would attempt to load the specified class (failing gracefully if it could not be found) and would pass its constructor the base Conf object. The returned object would be passed back to SpamAssassin.pm. This is basically a version of the Virtual Constructor design pattern. Advantages: - existing user's configs would not be effected - all conf decisions would be moved to the conf classes, rather than being somewhat scattered as they are now - an install like mine could reduce their text configs to a couple of lines in one system-wide file. - the actual config choices could be made using any method - sql, ldap, pychic divination, etc. - no code changes would need to be made by end users - conf modules that proved widely useful could be added to a contributors directory within the distribution - modules like DBBasedAddrList.pm could be loaded by the conf object, making the choice of which subclass to use more flexible. Disadvantages: - for maximum flexibility all Conf hash accesses in the current code would need to be converted to method accesses. - this is also why I can't just use your patch directly. - access to the configClass tag would need to be restricted to system config files to prevent user abuses of privileged programs like spamd. - slightly higher startup overhead. - the existing sql-pref system would probably need to be called differently than it is now. If this system does fit with SpamAssassin's plans for the future I'd love to see it incorporated into the main distribution at some point. I'm likely to have to make changes like this anyway (because of the oddities of my very large installation). The more people that benefit from my dev team's effort the better. I'd still be delighted to hear more alternatives/additions/criticisms for my proposed system. (on or off-list). Thanks to all for the comments and patches I've gotten so far. Richard Sonnen -- Richard Sonnen | Front Range Internet, Inc. [EMAIL PROTECTED] | www.frii.com [EMAIL PROTECTED] Web Programmer | 970-212-0731 800-935-6527 _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
