-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Daniel Quinlan writes: > Michael Parker wrote: > >> Which might be ok, but I can promise you that someone is going to go > >> through and either rm init.pre or comment out every loadplugin line > >> and then start asking questions about why their system isn't > >> autolearning. > > Losing autolearning if someone deletes init.pre is completely > acceptable. Autolearning *should* be optional and pluggable. Making it > pluggable allows people to experiment and try out other autolearning > mechanism and I suspect we'll see some usage of the API soon. ;-) > > We could also add a new autolearn state like "notloaded". That may indeed be a good idea, since this is now a new way for people to screw up their configs ;) > Theo Van Dinter <[EMAIL PROTECTED]> writes: > > >> I think we should shoot for a goal of when all plugins are disabled > >> the system should still do the right thing. If that means that we at > >> least provide a default inline that can be overridden by a plugin, > >> then that is how we should do it. > > Not autolearning if it has been disabled *is* the right thing. Things > work fine if autolearning is off. > > Also, our current autolearning code does not improve results by that > much in practice (which is why it needs to be revisited and other ways > to autolearn to be explored). See Gordon C.'s paper for those results. > > > I'll provide a slightly different version: for code that people are > > likely not to override (such as autolearning), we should probably just > > have it be in the code by default and let plugins override as > > necessary.. > > I disagree in this case, although I think there are probably some cases > where things are likely to not be overridden. Users are going to > encounter plugins and they're now a major part of basic SpamAssassin > functionality (much like Apache httpd, incidentally) not a coincidence... >, we should just > document things well enough. If people comment out stuff without > thinking, then there's not too much we can do about it. That's true. init.pre is exactly analogous to httpd.conf; an Apache install can be rendered thoroughly useless by turning off the wrong plugins. > For plugins that are likely to not be overridden, I'd be fine with > splitting init.pre into two or more files, like: > > standard.pre > optional.pre > experimental.pre > > or whatever. That would go a long way to guiding people as to how > seriously they need to think before commenting stuff out. And, FWIW, I think I wrote the "pre" code to load all files that end in ".pre", so this should work if we want that. > Of course, I agree ** 100% ** that everything should work as in "not > fail" if all plugins are commented out. There might be a few cases > where plugins have cross-dependencies, but we should make sure our code > deals with those and acts appropriately (warn, die, dbg, or whatever, > but *no* straight Perl interpreter errors!). > > Also, putting a line next to the AutoLearnThreshold load line such as: > > # at least one AutoLearn plugin needs to be loaded for autolearning to work > > is more than enough to prevent a stupid commenting out. If people just > comment stuff out without thinking or delete init.pre, we can't save > them. OK, I agree with everything in this message ;) - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFB/r9DMJF5cimLx9ARAvKkAJwJ9pXdNHpGBdanCZsRwsRzWZN9sQCggoQn DcAYHloban14xSGPq2dXvaU= =25W7 -----END PGP SIGNATURE-----
