Federico Barbieri wrote:
>
> Ok... Here's my purpose:
>
> Decouple match and mailet element in the conf so that first define the
> processing tree and seconds fill it. Here's an example:
>
> <processingPipe>
> <match condition="Spam">
> <mailet name="Null"/>
> </match>
> <match condition="RecipientIsLocal">
> <mailet name="Log"/>
> <match condition="[EMAIL PROTECTED]">
> <mailet name="top-secretDecript"/>
> </match>
> <match condition="RecipientIs=[mailinglist]">
> <match condition="HasAttacment">
> <mailet name="BounceAttachment"/>
> </match>
> <match condition="RecipientIs=mylist">
> <mailet name="Mylist"/>
> </match>
> <match condition="RecipientIs=yourlist">
> <mailet name="Yourlist"/>
> </match>
> </match>
> <match condition="RecipientIs=[lowusers]">
> <match condition="SizeIsOver=500k">
> <mailet name="BounceOversize"/>
> </match>
> <mailet name="LocalDelivery"/>
> </match>
> <match condition="RecipientIs=[highusers]">
> <match condition="SizeIsOver=2000k">
> <mailet name="BounceOversize"/>
> </match>
> <match condition="UserIs="pluto">
Note: the line above is invalid XML!!!
> <mailet name="plutoForward"/>
> </match>
> <match condition="UserIs="minnie">
> <mailet name="minnieImOnVacation"/>
> </match>
> <match condition="UserIs="topolino">
> <mailet name="topolinoForward"/>
> </match>
> <match condition="UserIs="paperino">
> <mailet name="paperinoTranslator"/>
> <mailet name="LocalDelivery"/>
> </match>
> </match>
> </match>
> <mailet name="RemoteDelivery">
> </processingPipe>
Ok, there are two possible ways of doing this:
1) procedural (as Federico is proposing)
2) declarative (as I proposed)
To summarize:
1) procedural
if (testA)
if (testB)
do something
fi
if (testC)
do something else
fi
fi
2) declarative
do something when testA and testB
do something else when testA and testC
Procedural languages are easier to see for programmers, expecially those
who never used a declarative language in all their lifes (like Federico)
[not necessarely a problem, just a fact]. Declarative languages are
harder to understand for programmers, but easier for non-programmer.
What I totally dislike about Federico's proposal, it's the
programmability of it. What you're writing is a procedural language for
mailet composition and mapping.
Instead, I would like to see a "description" of the address space, or,
in other terms, a "mailmap". I still believe that the center of
everything is the recipient mail address, just like the URI for HTTP.
> This define a tree and each </match> is a leaf where the pipe ends thus
> after each match spit a mail (recipients) there is no merge back. I
> cannot draw the tree just with ascii... :-(
That's the point. You can't even draw it with ascii! It's much harder to
visualize it. To find out what happens when your mail is sent to
"[EMAIL PROTECTED]" you have to "debug" your flow.... Also, if you
change one leaf, you could be messing up with the whole tree.
> Nested match are not really necessary but they make easier writing
> conditions. Instead of
>
> match="LocalUser & UserIs=pippo"
>
> you can write
>
> <match condition=LocalUser>
> <match condition=UserIs=pippo>
> ...
what about "or"?
> More than all spitting match element from mailet element allow mailet
> chaining whic IMO is a MUST.
Of course mailet chaining is a must, but while your proposal could end
up being less verbose, a declarative approach is much less expensive to
maintain in the long run and much easier to patch by different people
with different programming histories.
What you're writing is nothing different from
if (mail.getRecipient().equals("[EMAIL PROTECTED]")) {
if (condition(mail)) {
execute(myMaylet, mail);
}
}
just written using another syntax, but the paradigm is clearly the same.
Which goes directly to the M4 sendmail problem of having configurations
that are a programming language on their own.
> The second point is to use names instead of class (instances) inside the
> tree definition so that mailet instance can appear in different places
> in the tree. Mailet configuration should go somewhere else:
>
> <mailets>
> <mailet name="Null" class="Null">
> </mailet>
> <mailet name="Log" class="LogMailet">
> <repository> file://../var/mail/logs/local.log</repository>
> </mailet>
> <mailet name="top-secretDecript" class="Decriptor">
> <secretkey> mykey </secretkey>
> </mailet>
> <mailet name="BounceAttachment" class="Bounce">
> <message> Mail with attachment are not allowed for this
> recipient </message>
> </mailet>
> <mailet name="BounceOversize" class="Bounce">
> <message> This mail is over admitted size </message>
> </mailet>
> <mailet name="Mylist" class="MiniList">
> ....
> </mailet>
> <mailet name="LocalDelivery" class="LocalDelivery">
> ....
> </mailet>
> <mailet name="plutoForward" class="Forward">
> <forwardTo> [EMAIL PROTECTED] </forwardTo>
> </mailet>
> <mailet name="" class="">
> </mailet>
> <mailet name="topolinoForward" class="Forward">
> <forwardTo> [EMAIL PROTECTED] </forwardTo>
> </mailet>
> ....
> </mailets>
I agree with this. Also, as a suggestion, you should use XML "id"
attribute instead of "name" which is automatically enforced by XML
parsers.
> Such a sintax should make configuration more readable and powerful
> avoiding the risk of a "ad hoc" scripting language.
I say exactly the opposite. :)
my proposal? much flatter with the use of <continue/> and <stop/>
<mailmap>
<mailbox name="*">
<match id="spam">
<stop/>
</match>
<match id="local">
<continue/>
</match>
<mailet id="remoteDelivery"/>
</mailbox>
<mailbox name="*">
<mailet id="log"/>
<match id="DESEncripted">
<mailet id="DESDecript">
</match>
<match id="RSAEncripted">
<mailet id="RSADecript">
</match>
<continue/>
</mailbox>
<mailbox name="*@lists.apache.org">
<match id="hasAttachment">
<mailet id="bounceMessage"/>
</match>
<continue/>
</mailbox>
<mailbox name="[EMAIL PROTECTED]">
<mailet id="jamesList"/>
<stop/>
</mailbox>
<mailbox name="[EMAIL PROTECTED]">
<mailet id="avalonList"/>
<stop/>
</mailbox>
<mailbox name="*@apache.org">
<match id="messageTooBig">
<mailet id="bounceMessage"/>
</match>
<continue/>
<mailet id="localDelivery"/>
</mailbox>
<mailbox name="[EMAIL PROTECTED]">
<match id="messageIsHTML"
<mailet id="stripJavascript"/>
</match>
<mailet id="forward">
<parameter name="address" value="[EMAIL PROTECTED]"/>
</mailet>
<stop/>
</mailbox>
<mailbox name="[EMAIL PROTECTED]">
<mailet id="bounceMessage">
<parameter name="message" file="vacation_message.txt"/>
</mailet>
</mailbox>
</mailmap>
while this seems a hack to flatterize the tree at first, you should note
its object orientation: what you do is extending each mailbox matching
with some further parameters.
Also, such a schema allows you to "include" mailmap fragments and let to
each user or subgroup include their schemas without having to tune the
tree too much for that. This is important for ISP or places where a
single mail server handles multiple domanins and each domain has
separate policies maintained by different individuals.
While my proposal is more verbose and harder to compose at first, it's
easier to manage in the long run.
I suggest you to play around with this idea a bit before judging....
it's the same for XSLT: it appears very strange at first, because your
mind doesn't work that way... but it's easy to find out that this is the
way it worked before you learned programming :-)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
