Federico Barbieri wrote:
>
> Stefano Mazzocchi wrote:
> >
> > >
> > > I like the idea of a MailServletequest and MailServletResponse since
> > > this patter is really evident and well known. But since this do not
> > > allow forking... consider this:
> > >
> > > public void service(MailServletRequest req, MailServletResponse res)
> > >
> > > MailServletRequest gives you methods to easily access routing info,
> > > headers and read body
> > > MailServletResponse has some methods like
> > > copyBodyFrom(MailServletRequest req) and copyMailFrom(MailServletRequest
> > > req) etc to make easy and painless duplication of messages.
> > >
> > > This is just a filter and do not allw forking.
> > >
> > > Adding to the AbstractMailServlet a method like
> > > MailServletResponse getNewMailServletResponse()
> > >
> > > gives the mailServlet the ability if necessary to fork a message while
> > > should not make
> > > criptic the use if just a filtering is needed.
> > >
> > > some example...
> > >
> > > <processor match="[*]" class="Find">
> > > <find> aliens UFO cospiration </find>
> > > <action> mailto:[EMAIL PROTECTED] </action>
> > > <action> mailto:[EMAIL PROTECTED] </action>
> > > </processor>
> > >
> > > IMPLEMENTATION
> > >
> > > public void service(MailServletRequest req, MailServletResponse res) {
> > > res.copyMailFrom(req);
> > > InputStream in = req.getBody();
> > > if (findInStream(in, "aliens UFO cospiration")) {
> > > MailServletResponse alarm = this.getNewMailServletResponse();
> > > alarm.setSender("james@myhost");
> > > alarm.copyMailAsAttachment(req);
> > > alarm.setSubject("alarm");
> > > this.send(alarm);
> > > }
> > > }
> > >
> > > while a simple MailingListServlet...
> > >
> > > public void service(MailServletRequest req, MailServletResponse res) {
> > > res.copyMailFrom(req);
> > > res.setRecipients(thisListRecipients);
> > > }
> > >
> > > Sounds good to you?
> >
> > Hmmmm, the above is still a filter.
> >
> > mail --> ufo cospiracy mail servlet -> untouched mail
> > |
> > v
> > signal
> >
> > the signal is a log signal. If this logs gets forwarded as a mail
> > message, or stored into a database, this is _NOT_ of mail servlet
> > concern. This is a system dependend feature. Same thing happens in case
> >
> > mail -> james -> mail
> > |
> > V
> > critical error
> >
> > that is gets forwarded to your pager, nothing different.
> >
> > So, instead of extending the Mail Servlet API, I'd write something like
> >
> > public class UFOCospiracyMailServlet
> > extends JamesSignalProducer
> > implements MailServlet
> > {
> >
> > public void service(MailServletRequest req, MailServletResponse res) {
> > res.copyMailFrom(req);
> > InputStream in = req.getBody();
> > if (findInStream(in, "aliens UFO cospiration")) {
> > signal("UFO", req.getSender());
> > }
> > }
> >
> > that also allows you to "decouple" molder and schully from the
> > parameters of this servlet, which job is to filter a mail, not to send a
> > message!!!
> >
> > Do I make sense?
>
> Do not completly agree.
> Agree most of mail servlet only acts like filter. Some others produces
> signals (events that are "mail independent").
> But take Serge ImOnVacation Servlet. It let any incoming mails pass
> untouched (maybe a footer like "was replied by ImOnVacation") and
> generate a new mail as reply. This I'm sure is not an event.
> The easiest way to manage this is: the servlet may open anSMTP
> connection with JAMES and send the new mail.
> Of course this work perfectly even with my MailingListTranslator
> servlet.
>
> Since Forking mail servlet are 1% or so maybe this is the best solution
> but I want to throw another couple of ideas into this brainstorm:
>
> <!-- common processor pipe beginning --!>
> <processor match="[*]" class="AddHeader">
> <header> Recieved from ... by JAMES </header>
> </processor>
>
> <!-- forking point. one mail will follow subpipe 1 --!>
> <fork name="fbi" match="[*]">
> <!-- subpipe 1 --!>
> <processor match="[*]" class="Find">
> <find> bomb president tessosism </find>
> <action> mailto:[EMAIL PROTECTED] </action>
> <action> mailto:[EMAIL PROTECTED] </action>
> </processor>
> </fork>
> <fork name="fbi">
> <!-- subpipe 2 --!>
> <processor match="[EMAIL PROTECTED] or to=badboy@[*]"
> class="Null">
> </processor>
>
> <processor match="to=james@[localhost]" class="Archive">
> <repository> jamesarchive </repository>
> </processor>
>
> <processor match="to=james@[localhost]" class="MailingList">
> <list> james </list>
> </processor>
>
> <processor match="to=jam@[localhost]" class="MailingList">
> <list> jam </list>
> </processor>
>
> <processor match="to=admin@[localhost] or to=root@[localhost]"
> class="Forward">
> <forwardto> scoobie@[localhost] </forwardto>
> <forwardto> [EMAIL PROTECTED] </forwardto>
> <forwardto> [EMAIL PROTECTED] </forwardto>
> </processor>
>
> <processor match="to=mario@[localhost]" class="Translator">
> <language> italian </language>
> </processor>
>
> <processor match="to=natasha@[localhost]" class="Translator">
> <language> russian </language>
> </processor>
>
> <processor match="to=scoobie@[localhost]" class="Forward">
> <forwardto> [EMAIL PROTECTED] </forwardto>
> </processor>
>
> <processor match="to=faxto[*]@[localhost]" class="FaxSender">
> <userrepository> faxrepository </userrepository>
> </processor>
>
> </fork>
> <!-- end of forking. After that the two mails follow the same flow. --!>
>
> <processor match="to=[*]@[localhost]" class="LocalDelivery">
> <repository> localInbox </repository>
> </processor>
>
> <processor match="to=[*]" class="RemoteDelivery">
> <outgoingmailserver> mail.tin.it </outgoingmailserver>
> </processor>
>
> I force the processor pipe to fork and to join again before delivery.
> This means forking appends in the reactor, it's transparent for mail
> servlets and it's up to the administrator.
>
> processor 1
> |
> processor 2
> |
> forking
> / \
> processor 3 processor 4
> | |
> processor 5 processor 6
> | |
> processor 6 |
> \ /
> \ /
> end of fork
> |
> processor 7
> .......
>
> Comments ?
We are developing JAMES to avoid the complexity of things like Sendmail.
Following these paths is _exactly_ what I want to avoid.
True, creating a side SMTP message calling a socket is a dirty hack, but
if you think about it: the real behavior is the filter one. What is
triggered "on the side" may not be always a signal, I agree with you,
but it's an "action".
And this action may allow for creating a web page, sending faxes, using
a serial connection to page me, whatever... By introducing mail forking
hooks, we are simply imposing more weight on the send-mail action and
less on all the other things.
I don't mind having the functionality to send a mail using this action,
not at all!, I'm just concerned about introducing forking hooks into the
mail servlet platform.
If you want to write something like
ImOnVacation extends JamesMailSender implements MailServlet
i'm all for it, as long as there is no way in the MailServlet API to do
this. (and please, let's keep the configuration simple)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
