Well BeanShell or whatever is fine so far as scripting but no matter what we cannot avoid "bindings". Meaning supplying WHAT objects should be managed. JSR-223 seems not perscriptive so far as the scripting langauge. I'm not against that, but we should have something preferred. I originally kind of favored JavaScript figuring it was a more commodity skill than is Java itself. However, BeanShell is close enough.

An objective ought to be non-java programmers. Something that makes it easy for that group is good. A secondary objective ought to be "protection" meaning you ought not be able to change things through the scripting system that will destabilize the system (although they may produce undesirable mail-routing behavior).

Anyhow start thinking about how it would work and what is required to make it work. I'm less interested in "pick-a-standard" than the overall design of the thing and how it affects things like the Mail object. (meaning what needs to change). How should these be loaded? I kind of lean towards a custom deployer....etc

Is there a reason why JBoss Mail shouldn't adopt the Apache James Mailet / Matcher API? It seems well documented and is a stable, well thought out API for e-mail workflow processing.

Honestly, I've looked at (am still looking at) James as an e-mail server solution for an upcoming project. I suppose the main reason I haven't simply embraced James is its reliance on the now-defunct Avalon project. I cringe at the thought of introducing yet-another server framework into my development and production environments! J2EE, for all its flaws, is well known, mature, stable, and very well documented/supported.

I've been monitoring the JBoss effort, but am not at all clear that it's not going to ask me to don a different style straight jacket than James wants me to wear. The talks about relying on BeanShell or JavaScript to process e-mails handled by my Java-based e-mail server is an example of such a straight jacket.

To more fully discuss these issues, I'm posting a new topic on "What I'm Looking For, And Not looking For, In A Java-Based Enterprise E-mail Server"

Jack

Look, there is very next to no chance we'll use anything from JAMES. The pieces we DID use from JAMES are being ripped out because they didn't profile well (namely the layered streams). The mailet API may be well documented but its frankly not that good. Furthermore the goal is very different. Our mail API will be geared to allow non-developers to script mail stuff. If you want something different, use the MailListeners which you'll find more similar to JAMES.

I would however encourage an affirmative and positive "What I'm looking for". No one will make you use mail scripting. Just because YOU don't see value in it doesn't mean others (me for instance) won't. I intend to SYNDICATE my spam catch scripts and AGGREGATE those of others in my trust circle.

Furthermore, some clients already have contacted me asking when they'll be able to integrate with workflow and this and that for their mail. A scripting approach will make this available even to administrators. Not that we won't have a heavy java based one, but it most decidedly won't be JAMES's.