james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Proposal: new approach to spooling
Date Wed, 14 Jun 2006 08:56:56 GMT
I currently have a MailProcessor interface that has a
"Mail[] process(Mail input)" method and return 0..n mails for each mail 
processed. This allow me to support splitting of mails without the 
mail.setState, sendMail(mail) "hack".
Much more have to be done to that MailProcessor interface but I'm not 
able to plan it without working on the real code.

We should also keep in mind the Delivery Status Notification services 
while thinking at this changes.

Imo the *must* are a little different:
a) letting the mailet indicate that it consumed the message
b) letting the mailet return multiple mails (resulting from a split, or 
newly generated) without the use of sendMail.

The injection in another spool could be eventually still done with the 
state attribute or with mail attributes or anything else but I think the 
main problem now is not being able to split messages in a correct way.

Just think at a mailet that have to process a mail differently for each 
single recipient: we now have to use the sendMail hack and it does not 
work well.


Serge Knystautas wrote:
>> And, yes, the queue manager would continue to be responsible for 
>> calling the
>> processor to handle each message.  Each queue manager would be registered
>> with the MailetContext, which would be provided to the processor in 
>> order to
>> allow it to put messages set to a new processor (if we keep the currently
>> Mailet API).  We might provide a suitable error or exception on the
>> Mail.setState call if we try to address a queue (processor) that does not
>> exist.
> If I had to do any one thing about the mailet API over, it would be
> Mail.setState.  I think it's very counterintuitive and just doesn't
> make sense.  What it is simulating...
> a) letting the mailet indicate that it has consumed the message.
> b) injecting this mailet into another spool
> We then do mailconfig.sendMail to simulate b) in another areas.  It's
> just really messy... the constants make no sense and nevermind the
> terrible name "Ghost" to say a message is consumed.
> Anyway, so rather than checking on mail.setState, provide a way the
> message into another spool and fail there, deprecating mail.setState
> a.s.a.p.

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

View raw message