My 1 cent here:
Why if so the mail servlet api should reside on server, and not be something
like "mail client bot framework", i.e. reside on the client? It can be then
integrated seamlessly with all the existing mail servers (sendmail,
exchange, ...)
Daniel
Serge Knystautas wrote:
> Federico,
>
> Glad to see you're actively working on James. I should be leaving for a
> meeting now, but here are my quick 2 cents: My approach was designed on
> the assumption that 90%-95% of the time, you're not making a significant
> change to the email message (if any)... you're changing a header,
> rerouting this message, etc... My approach was more a mail filter than
> a request/response system (which I had trouble when I started
> considering usages of this).
>
> I *agree* it would be nice to support forking messages, but I never was
> happy with anything that supported this approach because then most of
> the time, it's a pain... do you have a Vector or array of response
> messages? I'm thinking the best way we can do this is to offer a
> convenient clone () method (either called directly on the Message object
> or through the message queue handler). You could clone the message,
> make whatever modifications to the new fork you want, and have it
> properly go into the message queue in an identical situation as the
> other. Reasonable?
>
> Serge
>
> Federico Barbieri wrote:
> >
> > Last days I was wondering what is the best way to define mail servlet
> > interface.
> > I looked both at Serge implementation and Stefano and Pier Mail Servlet
> > draft and I realyze there is a limitation: both definitions allow a mail
> > servlet to receive only one mail as "request" and generate only one
> > "response".
> >
> > This is enought for mail servlet like a mailinglistservlet which only,
> > from the request message, expand recipient list and add some footer.
> > My point is: do we need a mail servlet to produce more than a response
> > from an incoming message?
> > I was thinking to something like a mailservlet whitch examine incoming
> > messages and produce a new mail if some condition occurs. In this case
> > one message enter the mail servlet and one or two (the old untoched
> > message and the new one) different messages exit.
> >
> > Another example can be some translation servlet which translate incoming
> > messages to the user preferred language:
> > I can write
> >
> > <processor match="to=mario@[localhost] or to=natasha@[localhost]"
> > class="Translator">
> > <translate user=mario language=italian/>
> > <translate user=natasha language=russian/>
> > </processor>
> >
> > This meand the servlet take the same message sent to mario and natasha
> > and produce two different output messages.
> >
> > Since such things cannot be done using both Serge or Pier and Stefano
> > pattern I was wandering if someting more powerful could be needed.
> >
> > Am I on the right way or just thinking too big?
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/>
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
