Federico Barbieri wrote:
> 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.
I think any new messages should be put at the beginning of the queue
(possibly enabled with a method on the servletcontext rather than
requiring a new Socket connection back into James).
> 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 ?
>
> Federico
While I do like the XML structure on the whole, I think forking is a
crippled implementation of filter workflow and implemented in the wrong
place. [http] Servlets are great because you can forward or include
another servlet and wrap any programming logic around that from within a
servlet. Maybe we should support this kind of dynamic workflow... I
think introducing these programming concept in the admin file isn't the
right place. If you're going to introduce conditional flow into the
admin's control of servlet flow (if-then-else), I would just as soon
finish and provide rudimentary programming... support loops, gotos,
variables, etc... Obviously this very quickly becomes extremely
complicated, and honestly, we have no idea whether this is a necessary
functionality... we're just talking lots and lots of "what-if"
scenarios. We have a growing list of possible uses, but there's nothing
really like James out there... easily programmable mail filters. There
are some Java mail servers, but this is well beyond that... we had that
a year ago with the initial code import. What about a mail server that
plays MP3s that you send in an email... either attach the MP3 in the
message itself or some URL to grab the MP3 at. Send it to
[EMAIL PROTECTED] Hook up nice speakers to your mail server,
and you have a cool shared jukebox.
All I'm saying is we've got 90% of a mail server based on a good (not
great) design and built upon a great Avalon framework. I really think
we should table this analysis [paralysis] until we have some real use
experience with mail servlets... can't we just get a 1.0 out first and
get some lessons learned before we redesign everything? From out of
nowhere there's suddenly a surge of enthusiasm to get this done which is
fantastic!! I'd like to get that working against the code base ideally
to get us ready to publish.
Here's what I think at least needs to get done:
- rip out all the processing stages I had in my configuration and
delivery state object (if it isn't already)
- instead of having a paired object of Message and DeliveryState, make
it a single object MessageWrapper that contains the delivery state
information, and wraps the MimeMessage object.
- solidy how queues/objectstores work, and implement an efficient
implementation of the MessageWrapper object so the wrapped MimeMessage
object isn't instantiated and re-saved after every mail servlet... this
should be a dynamic onload and only save if changed. Ideally, the
MessageWrapper is actually stored as 3 files... a) delivery state
information (RCPT TO, etc...), b) message headers, c) message body (with
however many multiparts if applicable)
I don't know what else needs to get done in the Avalon framework to
release. With the above suggestion of making a MessageWrapper object
(or perhaps a better name), we can update the mail servlet API, finish
merging all changes so we're using the latest DNS code, a robust message
delivery and failure notices system, and publish the darn thing!
Serge
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
