Charles,
I posted this a while back in a different context, so here it is again - just a few
suggestions re: matchers etc.:
> The first option made me wonder whether it would be worth considering adding the
>facility
> to have multiple mailets for a single matcher, so that the syntax would change from:
>
> <mailet match="RecipientIs=analias" class="Forward">
> <forwardto>realname</forwardto>
> </mailet>
>
> to something like:
>
> <match matcher="RecipientIs" value="analias">
> <process mailet="Forward">
> <forwardto>realname</forwardto>
> </process>
> </match>
>
> or, in short form:
>
> <match matcher="RecipientIs" value="analias">
> <process mailet="Forward" value="realname" />
> </match>
>
>
> This led to a collection of fairly radical and present-syntax-breaking thoughts
>which
> follow:
>
> We could have multiple mailets in sequence to perform tasks like the one I
>described:
>
> <match matcher="SubjectStartsWith" value="FAX Message">
> <process mailet="Forward" value="fax-inbox" />
> <process mailet="LocalDelivery" />
> </match>
>
> This would also encourage mailets to simply process mail, not redirect. Redirection
>in
> the pipeline would become the task of a small set of standard mailets like
>ToProcessor. By
> default, mail would pass through mailets rather than being injected back into the
> matching processes at "root" or being absorbed. But by default, mail would be
>absorbed
> after a match (an extra passthrough="True" attribute on the match could specify that
>the
> mail should carry on).
>
> So you could have nice kinds of processing matches like:
>
> <match matcher="SubjectStartsWith" value="FAX Message">
> <process mailet="LocalDelivery" />
> <process mailet="RedirectTo" value="fax-printer-inbox"/>
> <process mailet="LocalDelivery" />
> </match>
>
> or
>
> <match matcher="UserIs" value="johnsmith">
> <process mailet="LocalDelivery" />
> <process mailet="ForwardTo" value="johnsmith@home">
> <addmessage>John, this arrived for you today at
>work.</addmessage>
> </process>
> <process mailet="RemoteDelivery" />
> </match>
>
> or
>
> <!-- The passthrough ensures that this mail is still delivered locally like
>everything
> else -->
> <match matcher="UserIs" value="johnsmith" passthrough="true">
> <process mailet="ReplyToSender">
> <timeperiod startdate="2000-12-10" enddate="2001-01-05" />
> <message>I'm on holiday at the moment, but I'll get back to
>you when I'm back in the
> office on the 5th of January.</message>
> </process>
> </match>
>
> You could also have submatches:
>
> <match matcher="UserIs" value="john,js,johnsmith">
> <match matcher="SubjectContains" value="URGENT">
> <process mailet="RedirectTo" value="john@home" />
> <process mailet="RemoteDelivery" />
> </match>
> <match matcher="All">
> <process mailet="RedirectTo" value="johnsmith" />
> <process mailet="LocalDelivery" />
> </match>
> </match>
>
> or the facility to perform 'subprocesses' which would produce duplicates of the
>mail,
> process them an then absorb them, without interfering with other operations:
>
> <!-- The passthrough ensures that this mail is still delivered locally like
>everything
> else -->
> <match matcher="UserIs" value="johnsmith" passthrough="true">
> <match matcher="DateBetween" value="2000-12-10,2001-01-05">
> <subprocess>
> <process mailet="ReturnToSender">
> <addmessage>I'm on holiday at the moment, but
>I'll get back to you when I'm back in
> the office on the 5th of January.</addmessage>
> </process>
> </subprocess>
> <subprocess>
> <process mailet="ForwardTo" value="johnsboss">
> <addmessage>John received this today by email,
>he's on holiday so you may want to
> deal with it yourself!</addmessage>
> </process>
> </subprocess>
> <subprocess>
> <match matcher="SubjectContains" value="URGENT">
> <process mailet="RedirectTo" value="john@home"
>/>
> <process mailet="RemoteDelivery" />
> </match>
> </subprocess>
> </match>
> </match>
>
> This kind of syntax potentially provides processing benefits:
>
> 1. Multiple mailets per matcher encourages configurations with fewer matchers which
> should be able to be processed more efficiently.
>
> 2. Subprocesses provide an opportunity and explicit method of multi-threading
> processing.
>
>
> ...just a thought!...
>
> Stuart.
>
On Friday, January 5, 2001, at 06:58 PM, Charles Benett wrote:
> Here's some ideas on the Mail Engine, for your comments.
>
> At the moment, you can configure a set of processors, each with a list
> of mailets.
> Each mailet config is, in effect an if..then: if (matcher) then
> (mailet).
> There is only one class of processor (Linear Processor). It checks for
> recipients of a Mail that match the matcher. A mail with the matching
> recipients is passed to the mailet. (If there are non-matching
> recipients, a duplicate Mail with them drops through to the next
> matcher) (Matchers such as SubjectInFakeDomain, ir they match, respond
> with all recipients.)
> A mailet passes a Mail to another processor by changing the state of the
> Mail.
>
> I was simply going to formalize the current structure using the new
> Avalon Interfaces of Stage and Pipeline. But thayt lead me on to a few
> questions about how best to do this processing. Partly reflecting
> comments on the list over the last few months.
>
> How about:
> 1) if..then..else stages?
> 2) boolean matching criteria, e.g. if (matcher1) && (matcher2) then
> mailet?
> 3) Would it be useful to have more explicit processors, a bit like a
> Linux 2.2 firewall system, e.g. incoming, forwarding, outgoing?
> 4) Would it then make sense to have matchers that return boolean, e.g.
> for SenderOnSpamBlackList, with an alternative class of processor that
> uses them?
> 5) There was a suggestion, I think from Peter, that it might be more
> efficient to split each Mail by recipient early, then process each
> single-recipient Mail seperately.
>
> Comments? Requests? WIsh lists? Offers of code?
>
> Charles
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
>
-------------------------------------------------------------------------
Stuart Roebuck [EMAIL PROTECTED]
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS http://www.adolos.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
