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-----