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.
Stefano
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
