james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: Sieve Proposal (Request For Comments)
Date Thu, 11 Dec 2003 15:23:17 GMT
Danny Angus wrote:

Hi Danny,

Sorry for the delay in replying.

> 1/ modify existing James Container to support alternative
> processor types
> than "LnearProcessor"

I am rather hoping that, perhaps in vain, that someone else might take this
on while I do (2) below.

> 2/ develop a sieve processor

70% done.

> 2 could go in contrib,

'contrib' where? The sieve processor is currently packaged as
org.apache.sieve, though this could change. Its purposely not
org.apache.james.sieve as its totally independent of James (and Avalon).

> I'd strongly urge you to try (without driving
> yourself into an asylum) to make this truly a component, such
> that it can
> be built, as far as possible, without access to James using
> only the mailet
> (and 3rd party) API(s). Where Mailet API changes are
> indicated bring them
> back here. This would not only achieve the sieve
> functionality but pave the
> way for the development of further alternative processors.

This should be relatively simple (I'm probably going to regret saying that).
As implemented, the Sieve processor has a very simple interaction with the
invoking object. Wrapping it as a component would not even require the
Mailet API.

Assuming that the scripts were managed by the Sieve component, all the
invoking component would need to do would be to pass:
- The identity of the script to run
- A mail instance to be processed that implements the interface

During evaluation of the mail against the chosen script, the Sieve processor
pushes Actions onto a stack within the MailAdapter. On return, the invoking
component is expected to perform the Actions on the stack.

Actions are things like discard, redirect, fileinto, etc. Things that the
invoking component already knows how to do well. Back in James land, the
MailAdapters would wrap instances of org.apache.mailet.Mail and we might
very well map the Actions to Mailets so that on return from Sieve we invoke
them in the order they are on the stack.

Still, this related to (1) above, so I shouldn't even be thinking about it

> I'm tempted to resurrect the debate about why processors are not
> specialized Mailets , but I'll just mention once it and see
> if anyone has
> anything new to say. :-)

Well no takers during the past week or so. Maybe when someone looks at doing
(1) above?

-- Steve

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message