----- Original Message -----
From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
To: "Java Apache Mail Server" <[EMAIL PROTECTED]>
Sent: Saturday, February 05, 2000 2:17 PM
Subject: Re: Mail servlet
> Sorry for jumping in late on this...
>
> 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".
>
> Yes, both were designed to _impose_ such a limitation. I remember an old
> time discussion on this mail list about that.
>
> > 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?
>
> <strong-opinion>
> we don't!
> </strong-opinion>
>
> I had a long phone discussion with both Federico and Pier about this:
> mail forking should be considered "flexibility syndrome" and avoided as
> a plague. The reasons are:
>
> 1) a filter is _never_ meant to be a multiplexer
> 2) a filter has one channel in and one channel out... if other
> communication is needed, this is performed sideways (the T-model from
> electronic filters).
>
> in ---> filter ---> out
> |
> V
> signal
>
> 3) all possible "signaling" requirements are system operations (logging,
> error checking, profiling information) and do not belong to "normal"
> mail servlets.
>
> > 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.
>
> This hurts the overall cleaness of the design, IMO.
Couldn't we simply associate a signal to a mail sender? If somethign
abnormal happens we could generate a signal and pass the original message to
a servlet for further processing..this means assign a servlet to a signal...
we are still forking, but without directly handling it... it's still like an
Exception thrown to someone... but it can generate a new message... like an
error message on a pager..or something less critical as an anti-spam advice
to the sender still delivering it's message... or something like this.
>
> > 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.
>
> This is not right: this can be easily done with a filter approach. In
> fact, the mail list servlet will expose more reciepients, then feed the
> mails back into the reactor. At this point, the mail is "translated" on
> a single reciepient base, like in any other processes.
>
> I could not come up with a need for forking that doesn't involve the
> sideways signaling model explained above.
That's right. I agree to the T approach: if someone, for a reason I could
not realize now, will REALLY and STRONGLY need to multiple fork a message
(it really exist this kind of situation?) it could serialize the T apprach
to obtain it or simplier could associate multiple signals to different
servlets instances... Have I figured out correctly your view Stefano?
-1 too for the forking
>
> So, my vote is a big -1 to forking.
>
> > Am I on the right way or just thinking too big?
>
> I believe this is big time flexibility syndrome.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <[EMAIL PROTECTED]> Friedrich Nietzsche
> --------------------------------------------------------------------
> Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------
>
>
>
>
> ------------------------------------------------------------
> 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]
