Federico Barbieri wrote:
> 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.
I don't think you even need to support that... I like the ServletContext
object (similar in concept to the HTTP Servlet API) which gives you
access to server instance level functionality. IMO, this would be a
great place to add a method to send new messages.... context.sendMessage
(MimeMessage message). Actually, you might want to make it sendMessage
(MessageContainer) because they may want to specify RCPT TO targets that
aren't in the headers of the MimeMessage.
> 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".
Cool.
> I was thinking to a MailServlet that phones you and read the mail...
> That's power! :)
Very cool.
> > 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".
Sure, I'm not sure how much information we'd really need... one idea I
had (to open a can of worms) was to allow support for generic object
storage in that State object... you can effectively get session handling
for a message object. An early servlet could flag a message as bulk,
and then your phone dialer servlet wouldn't call is it's that kind of a
message.
> > - 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?
I wasn't aware of the MessageContainer object, but it sounds like that
does what I'm talking about. This would be for the MailServlet
interface... servlet.service (MessageContainer container).
> > - 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!
Heh... sure. The objectstore has been a sticking point for me for a
while... are their particular classes in the avalon or james tree I
should look at?
> 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.
+1
> - 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.
+1
> - 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.
-1 as well
> 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...
I'm not sure what you mean filtered output... I figured you're passing
the State and MimeMessage object to the servlet (contained in the
MessageContainer object)... if you had to translate the message from
English to French, you would reconstruct the body of the message. If
you wanted to flag it as a bulk message to be put in a special folder,
you could add a header Delivery: Bulk. If you wanted to change who it
was going to, you'd change the recipients in the State object. What
other kinds of filtering were you talking about?
Serge
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
