Serge Knystautas wrote:
>
> 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.
Not sure about it... What a MailServletContext could be used for?
>
> > 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.
What is the different role of the State and MailServletContext in your
opinion?
>
> > > - 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?
>
It's still a bit rude but the Store interface implemented by
avalon.blocks.masterstore.MasterStore could be a good starting point. It
provide a simple mechanism to build Repository and these Repository are
pluggable. So since default Repository are Object and Stream, James
plugs its own MessageContainerRepository and use it.
I'm planning to write a Repository implementing javax.Folder to better
fit standards.
Planned Repository are: TransactionalRepository, SQLRepository,
XMLRepository etc.
Pay attention in the masterStore: if you define in configs a public
Repository name "Inbox" and the ask for a Repository named
:Inbox.scoobie" a new Repository is generated and it will be public as
the parent.
> > 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?
Forget it. I miss the point...
>
> Serge
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/>
> Problems?: [EMAIL PROTECTED]
--
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]
