Stefano Bagnara wrote:
1) Why should it contains create/start/stop/destroy and not the
configuration method?? if you think that configuration is made by
injection with no specific interface then why can't the
start/stop/create/destroy method be called in the same way?
Makes sense. In that case the interface can be eliminated entirely in
favor of annotations.
2) I think we have to add something better for the routing than Mail
service(Mail mail). We need a way to split a message into multiple
parts and let the container know this happened, we need a way to
bounce a message and let the container this happened, to forward to a
different address and let the container know this, to expand it to
multiple recipient and again let it know to dad.
Yes...bounce messages. I have a whole barrel of them from things that
scan the net and falsify the reply-to. Yes I know it is in the spec,
but generally turning it off should be an option.
I'm under convinced that the mail needs to be broken into multiple parts
and the container informed (this is should be about queues).
MailetChains process Queues (you guys call these Spools)
MailetChains post to Queues
Any mailet can terminate the chain (by returning null)
However I agree that more is needed for status. An idea that has been
discussed before on james-dev (some years back) and amongst our group
(some time back) was the concept of an envelope. In addition to moving
the attributes off of the Mail object (which can instead purely
represent the mail), we could add something like terminate(reason) that
the container can check to see if it should bounce the mail (by policy).
Postfix among others actually have a separate bounce queue. But I think
that I prefer the notification "this failed, here's why" and leave it up
to the container implementation (again my config will be "eat it" or
possibly "eat it unless it has a nice spam rating").
-Andy
I don't see anything better than the current mailet apis in this
interface, sorry.
Stefano
Andrew C. Oliver wrote:
package org.apache.mailet;
public interface Mailet {
void create();
void start();
void stop();
void destroy();
Mail service(Mail mail);
}
Main changes I'd like to avoid this holdover from Avalon
"Configurable" and
make configuration a matter of injection (so all MailetConfig is
removed).
I don't really see the need for the four stage lifecycle but this is
basic CS stuff. I'm happy to remove create/destroy if there is
consensus.
Generally I think Mailets will form chains. It strikes me as a
better model to not assume that the mail object going in is the one
that is ultimately delivered to the next mailet in the chain.
Thoughts?
-Andy
