You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by OpenMacNews <op...@gmail.com> on 2006/09/07 16:37:32 UTC

user-friendly app, plugin & rules loading & updating

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,

reading with interest the ongoing thoughts/discussion about v32x 
planning, rules mgmt, etc.

wearing my user hat (which is usually glued-on, anyway ...), i did a 
bit of "wish it could ..."

1st caveat:  this no doubt ignores, and tramples upon, some combination 
of common-sense, what already exists, and future code-planning. that 
said ...

as a user, i upgrade the app, plugins (some 'core', some not) and rules 
(again, some core, come not) on a regular, often asynch, basis.

in an ideal world, i'd like to see some consistency in/across

(1) config files
(2) upgrade methods

e.g.,

(a) app conf in 'local.cf' (the usual location hierarchy)
(b) plugin loading *only* in, say, "plugins.conf", wherein its the 
resonsibility of the end-user to move/copy the appropriate plugin 
identities & locations FROM the *.pre's
(c) rule-sets loading *only* in, say, "rules.conf".  i.e., turning 
on/off a rules set is no longer a matter of dropping the *.cf into the 
dir, but rather done in a parseable conf file.

that way, i don't worry abt "what's lying around" or in some errant 
directory, but rather *just* what i've explicitly enable in one place 
...

and, then, upgrades to any/all would be via:

	sa-update-app
	sa-update-plugins
	sa-update-rules

perhaps not even worth the usual $0.02 ...

richard

- -- 

/"\
\ /  ASCII Ribbon Campaign
 X   against HTML email, vCards
/ \  & micro$oft attachments

[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB  D460 95F7 DDBD 3671 08C6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iEYEARECAAYFAkUALqwACgkQlffdvTZxCMZePQCeKzWn7QCoJ7hWnHda4xgaz6mb
cVoAoLfAaJWnNAoOoNRiE4k3GZzQit7K
=iJVj
-----END PGP SIGNATURE-----