-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daryl C. W. O'Shea writes:
> Justin Mason wrote:
> > Hi Daryl --
> >
> > I've been thinking about this -- the ability for plugins to add
> > headers.
> >
> > If a plugin can add new template-tags (as described in
> > Mail::SpamAssassin::Conf), and the plugin's config file then
> > sets them using add_header, that should work, right?
> > That would be the best way to do it I think.
> >
> > - --j.
>
> (briefer this time, $%#* Thunderbird crashed again -- I think I'll go
> back to Pine)
>
> Using add_header makes adding static headers easier (well fewer
> keystrokes anyway) than editing the header hashes directly, but it
> doesn't offer any protection from two plugins trying to add the same
> header (say if I were to use a ClamAV and an F-Prot plugin, both might
> want to use X-Spam-Virus). There are one, maybe two problems with a
> plugin using add_header:
>
> 1) If two plugins add the same header, the last one wins (overwriting
> the first one's header data).
>
> 2) I haven't really looked into this since I haven't had a use for it
> myself, but I don't immediately see a way to add _custom_ dynamic data
> to a custom header (without editing the hashes directly).
Well, both are good arguments to keep that behaviour out of code, and in
the config file, such as:
in one file:
loadplugin MyAvPlugin
add_header all X-Virus-Status __MYAVPLUGINSTATUS__
in the other:
loadplugin MyOtherAvPlugin
add_header all X-Virus-Status __MYOTHERAVPLUGINSTATUS__
that way it's pretty clear to someone looking at the config file, that
those two are going to collide; and it's pretty clear how to fix it
(twiddle one of the add_header lines).
Basically, the idea is: the plugin can set whatever name for a
template-tag it likes -- and the config file then dictates what
the name of the header will be.
- --j.
> Provided I'm not missing something, two solutions may be:
>
> 1) On a per message basis, a plugin requests a header name, and is
> returned a header name (either the header it wanted, or that header with
> an integer appended). This will ensure that there aren't conflicts
> between plugins, but it makes the header name unpredictable.
>
> 2) A note could be made in the wiki and pod that sets a standard way of
> naming a plugin's headers. I suggest that the standard way would be:
> X-Spam-PluginName: or X-Spam-PluginName-Blah: (either would be
> acceptable to use).
>
> I think #2 would be the best solution (or #2 in addition to #1). #2
> would work with the current code, and we'd only have to threaten to make
> fun of people, or force them to drink American beer, if they don't
> adbide by it.
>
> Actually, now that I think of it, a 'plugin_add_header' method for use
> by plugins, that enforced #2, would probably be the best idea. This
> method would work like this:
>
> plugin_add_header(name, spam|ham|all, data)
>
> If a plugin were named 'CoolPlugin' you'd get the following headers,
> using the following name values.
>
> name = ''
> X-Spam-CoolPlugin:
>
> name = 'Virus'
> X-Spam-CoolPlugin-Virus:
>
> Anyway... maybe this isn't really an issue. Plugins, at least public
> ones, don't seem to be too popular as of yet, so conflicts aren't really
> an issue right now.
>
> Daryl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFB5HYIMJF5cimLx9ARAltzAKCtEm0mDRHe6X/X6f6AAocCOIkJqQCfcka2
cknlX4+83QuqQZJjvFo+r9E=
=Ry1+
-----END PGP SIGNATURE-----
