Noel,
> Please see my reply from a few minutes ago suggesting different syntax.
> With moving the configuration to an attribute on mailet, I don't have a
> problem with it. So far no comments from Danny, Serge or anyone else.
I have taken the approach of using child elements for two reasons.
The first is that I have in the past felt the need of having a richer way to interact
with matchers than just through the condition string, using instead child elements as
with mailets. For instance, when I modified Cesar Bonadio's antivirus matcher, I felt
the <mailet match="..." ...> too "ugly" because there were so many parameters to pass.
But now I'm more "aesthetically" preferring the way it is now (matchers only accessing
the condition strings, mailets accessing child elements), because is more adherent to
an if (condition) then {block} appearance. I have in mind infact change the IsInfected
matcher to a VirusScan mailet followed by a "HasHeader=X-IsInfected" check: it is more
flexible to code a config.xml that way, and cleaner to understand. So I agree on
switching to attributes.
The second reason is that I saw immediately how to code it in LinearProcessor, while I
don't know how to access <mailet> attributes. I can dig around the code, but if you
could give me a hint ... ;-)
Wait a moment, I just found MailetContext.getAttribute(String). Is it that one? No, it
seems to be global :-(
>
> We can operate on the idea of a "lazy consensus", which means it is OK
> unless there is an objection. However, there are two things I would take
> into account:
>
> - Changes to branch_2_1_fcs have to be carefully considered.
> That is our stable branch. We should make every effort to
> keep it entirely stable.
>
> - Changes to the public interfaces should also be carefully
> considered, since they are the hardest to change after
> people start using them.
>
I think that the feature we are discussing is totally transparent and backwards
compatible, as defaults to the current behaviour. It is instead important not to
change the try/catch behaviour of existing matchers/mailets (other than the new
AttachmentFileNameIs, that simply should behave like HontvariJoszef wants).
Regarding what to do about per-recipient exceptions, instead of per-message
exceptions, I agree that we may handle it better in the future. To avoid future
backward compatibility in configuration files, we can change
matchException="[match|nomatch|error|aProcessorName]"
to
matchException="[matchall|nomatch|error|aProcessorName]",
and in the future to
matchException="[match|matchall|nomatch|error|aProcessorName]"
when we will hopefully support specific per-recipient exceptions. This way whoever
uses this new feature in config.xml knows that matchall matches per message.
> I have not committed your patches. You'll have your account shortly, and
> should be able to do so directly. :-)
Great, but please do commit for me now the patch to AbstractRedirect, as I am doing
small things here and there, and I would prefer not having a too big patch
accumulating different things.
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
