Pierpaolo Fumagalli wrote:
>
> Federico Barbieri wrote:
> >
> > Last days I was wondering what is the best way to define mail servlet
> > interface.
>
> If you're defining an interface, these are no more mail "servlets" in
> the strict meaning implied by the world "Servlet" (as defined by the
> Java Servlet Api specification).
> IMVHO we should, first of all, to avoid any confusion, find a new name.
> I had several talks with James Duncan Davidson (the previous maintainer
> of the Java Servlet Specification) and, as shown by the new 2.2 version
> of the spec, servlets are more and more evolving towards a unique HTTP
> model (even if they still keep a basic difference between javax.servlet
> and javax.servlet.http packages).
> In the past year, I realized that servlets are oriented to a request
> response mechanism, while, what we are looking at right now, is a modify
> and forward mechanism.
> The difference between those two models is that in the request-response
> mode, the stream generated by the "servlet" is sent back to the same
> client, while in the modify-forward is sent somewhere else.
>
Right. I should have said "design pattern" and not "interface".
Agree on name chage. Basically becouse even if "Mail Processors" (?) and
HttpServlet has really similar pattern they work really differnly:
HttpServlet replies to the client while Mail Processors talk with a
reaction mechanis. This means the first is tie to a "one enter one exit"
pattern wile the second is (in general) "one enter many exit".
> > 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".
>
> That's a limitation, in fact, imposed by the request-response model. We
> need to switch to a modify-forward (or modify-forward*) model, instead.
>
> > 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 don't see how we need to generate a different content for a single
> servlet call, but surely we need to be able to multiplex this output to
> different recipients:
>
> [EMAIL PROTECTED] send a message to [EMAIL PROTECTED] (request)
> [EMAIL PROTECTED] examines and modifies the contend (modify)
> and then sends it to [EMAIL PROTECTED] (forward)
> to [EMAIL PROTECTED] (forward)
> to [EMAIL PROTECTED] (forward)
>
> So, we can have request->modify->forward*
>
Different recipient of the same body are ONE message. This exampe do not
break the "one to one" pattern. See later...
> > 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.
>
> I cant' get what you want to do...
A sort of logging to a mailbox. If some condition occur in the mail
flow, mail the administrator to warn him. Foe example if a mail
containing an attachment called "crack" is sent from a local user I wont
to worn someone.
>
> > 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>
>
> I'd better see different processors based on the same class aliased on
> two different addresses, rather than one that does different things
> depending on "request data"...
>
> > This meand the servlet take the same message sent to mario and natasha
> > and produce two different output messages.
>
> Gotcha... But I'd prefer to see two different processors doing the same
> job...
>
Agree. But what about a mailing list translator? Users can be 1000 and
the list is dynamic. You cannot administer that from configrations.
> > 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?
>
> It is, IMVHO, too complicated and "not clean" (it's a feeling, can't
> explain it better)...
>
Agree. I still don't see any bright light. That's why I'm still thinking
and not writing any code... :)
> Pier
>
> PS. When the hell are you going to get here, DAMN! :)
> --
> --------------------------------------------------------------------
> - P I E R -
> stable structure erected over water to allow the docking of seacraft
> <mailto:[EMAIL PROTECTED]> <http://www.betaversion.org/~pier/>
> --------------------------------------------------------------------
> - ApacheCON Y2K: Come to the official Apache developers conference -
> -------------------- <http://www.apachecon.com> --------------------
>
> ------------------------------------------------------------
> 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]
