Take a look at this: http://james.apache.org/provided_matchers_2_1.html, and this: 
http://james.apache.org/provided_mailets_2_1.html.

James has an API called the "Mailet API".  Its a great idea but kind of an abortive 
impelmentation: http://james.apache.org/mailet_api_2_1.html.

"
The Mailet API is currently in its second revision. Although, the Mailet API is 
expected to undergo substantial changes in the near future, it is our aim that 
existing Mailets that abided purely by the prior Mailet API interfaces will continue 
to run with the revised specification.
"

I don't want to hook into their Mailet API, but rather implement some of the concepts 
mixed with some of our own.  Later I'll start pushing to come together and come up 
with a "standard" which implements some from both.  I know there are a (primarily 
uninvolved in more than commenting) number of peace/love commentors, but the secret to 
good design is divergence and reconvergence.  Its premature to cooperate.  Go look at 
the best standards and worst.  The worst were cooperative from the start, design by 
committee.  The best were competitive and then agreements were met on which ideas had 
been the best.

What I'd like to do is see us make a MailListenerChain interface which is itself a 
MailListener.  The MailListener interface is ATM not supposed to pull mails off the 
stack.  A ChainableMailListener would plug into the MailListenerChain and COULD pull 
messages off the stack.  

>From there we implement a concept like Matchers which can plug into a 
>ChainableMailListener.

ChainableMailListeners should ALSO be MailListeners so they CAN operate in either 
mode.  If they are not part of a chain, they do not consume messages from the stack.  
If they are part of the chain, they do consume messages from the stack where 
appropriate.  

Next, I'd like to do more than just statically compiled Java objects for mail 
processing.  For what I'd like to see us do, you need to look at Cocoon's flowscript.  
Cocoon is a vernable hotbed of good ideas gone bad.  Flow is one of them. 
http://cocoon.apache.org/2.1/userdocs/flow/api.html

Cocoon uses a Mozilla project called Rhino: http://www.mozilla.org/rhino/.  Rhino is a 
Java implementation of JavaScript (for all irony).  There is also jyThon 
(http://www.ociweb.com/jnb/archive/jnbMar2001.html) but there are reasons that I favor 
JavaScript to python.  The most important is that I see some admin types as writing 
these mail scripts.  JavaScript is more well known than python and probably anyone 
even somewhat introduced to the technical field has had a basic introduction to it.  I 
mean this is the first language of scripting.  

What the idea would be.  Matchers could be implemented in JavaScript as well as Java.  
We'd supply an object model which protects you from doing anything other than matching 
mails.  Secondly, a RhinoChainableMailListener could be used to do more advanced 
things with routed mails.  You could implement a set of spam filters for instance.

This has multiple implications.  We could also provide a system for syndicating 
JavaScript matchers for Spam filtering.  Basically an RSS feed from a server could be 
aggregated to provide an automatic method for syndicating filters for spam.   Meaning 
if I trust jboss.org and JBoss.org adds a matcher to its spam filter for all mails 
containing "V|4GR4" then it would be added to my matcher.  If your mail server trusted 
mine to provide this info, it would be automatically added to yours as well!  

So obviously I've left out some details and there are some rough spots to work out.  
In particular a potential impedence mismatch between MailListener, 
ChainableMailListener, matchers and mailets (part of the mail listeners).  I don't 
think that many people will use Maillisteners, rather they'll favor 
ChainableMailListeners.  However, SOME people will.  Remember, we're a solution 
framework as much as a mail server and not a single solution to a single problem or 
simple mail server (there are plenty of those).  

I'd like to get the idea flow flowing.  Lets hear them.  Please feedback and help me 
work out the details of this idea, ask questions, fight with me, etc.  Also post your 
own RTs for other ideas we might proceed.  Remember to put on your aspetos suit.  
We're all friends here but its important to fight through the ideas.  

Thanks,

-Andy

View the original post : 
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3831198#3831198

Reply to the post : 
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3831198


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to