Serge Knystautas wrote:
>
> 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).
Agree. Forcing any "forked" mail to be sent to the top of the processors
pipe is a good pattern IMO. Implementation cames later. I was thinking
to write an AbstractForkingMailServlet EXTENDING MailServlet adding some
sendMessage(MimeMessage message) method. Implementation may use socket
or just an internal loop back.
>
> > 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.
Agree. A linear processor pipe programming is powerful enough in most
situations. And more than that any tree like pipe programming can be
translated in a linear pipe using smart "mach". So since these two
representation are equivalent I suggest to force our attention on linear
programming 'till we find some useful situation for "generic graph
programming".
> 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.
I was thinking to a MailServlet that phones you and read the mail...
That's power! :)
>
> 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.
+1
>
> 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)
I say extend the state object to a more general concept. Say the
MimeMessage contains the mail while the State class contains routing
infos and maybe some processing infos like "UnableToSend. Try again in 5
hours".
> - 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.
This is what the MessageContainer does right now. Are you talking about
the MailServlet Interface or in general?
> - 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)
Agree. but this comes after we define interfaces and patterns.
Once design is great, smart implementation comes naturally!
>
> 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!
+1.
Avalon is complete enough to be usable. So let's make JAMES powerful
enough to make worth to use it and "and publish the darn thing!" !!
I spent last night with Stefano talking about the thing. We finally
comes to the conclusion that:
- whatever forking may be necessary this is considered and external
action and so do not relate with the reactor mechanism.
- The Request-Response pattern (which I like very much) is out of place
here and it should be better to use some simpler Message service(Message
msg) stuff.
- Take MailServlet under some Avalon patterns so they should extend
Configurable and Service
(maybe Composer and Component but I'm not sure about it)
In these last days I came up to the point that "the simpler the mail
flow is the easier to administer". Any MailServlet forking inside
reactor is an error because is slealing control to the administrator.
I know I was the one taking out this idea, after a week of ascetic
thoghts I'm voting -1 to reactor forking.
The only missing point in my mind is: since MailServlet need to act on
routing information (in the State object) how can we pass them to the
service and get a filtered output? Wrapping is not my favourite
solution...
Federico
*-----------------------------------*
"Troubles occurr when two people try
to be intelligent in the same time."
- Murphy
*-----------------------------------*
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
