----- Original Message -----
From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
To: "Java Apache Mail Server" <[EMAIL PROTECTED]>
Sent: Saturday, February 05, 2000 2:51 PM
Subject: Re: Mail servlet
> 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.
>
> No, the problem is that Servlets = HTTPServlet. If we change the name to
> "mailets" of shit like that, this will _always_ be the case.
>
> Anyway, if we precisely outline the differences between the two models,
> it's going to be easier to _merge_ them in the future because more and
> more people will understand their similarities and differences.
>
> I think servlet is a protocol abstract name. Servlet = httpServlet is
> wrong. We should not fail to provide better alternatives to this
> reasoning, since we can.
If they use HTTPServlet for Web related servlet why we are not using
SMTPServlet for Mail related servlets?
I agree with you: HTTPServlets are NOT all kind of servlets and the API we
are realizing is a Servlet one with no dubts.
javax.servlet.smtp should be the right package for it.
> > 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).
>
> As long as they don't add anything to javax.servlet.* that is extremely
> http oriented these are just words. If we don't fight for our rights
> now, we never will.
I think you used a wrong term: we are not fighting against Sun to convince
them about our work: people using this API will declare the correctness of
our thoughts. We should make a good work and the people will support it in
the same way as did with the Apache Web Server, the Apache XML Project, the
Apache Tomcat project and so on: the Apache Group is on top of the wave
(ovvero sulla cresta dell'onda [It]) and we can place another block in the
mosaic.
>
> > 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.
>
> Yep.
>
> > > 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.
>
> Hmmm (see below)
>
> > > 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*
>
> Servlets are based on request-response.
>
> Response is normally seen as "something that comes back to who
> requested". This is the only problem I see in javax.servlet.* for true
> protocol indipendence.
>
> But if we think at a response as "an effect caused by a request" (so
> abstracting the recipient), the whole model still holds true. You just
> have to _understand_ that different protocols route this response
> differently.
>
> Current model is
>
> request -> service -> response
>
> if we abstract the response from the recipient, servlets work for both
> SMTP and HTTP with no API difference, just different behavior (which is
> a good thing for OO reasons: MailServlet _extends_ Servlet, doesn't
> extend HTTPServlet!!!)
>
> We all know that chaining is bad because request != response so you
> can't do this directly
>
> request -> service -> reponse -> service -> response
>
> but you have to do
>
> request -> service -> response -> adapter -> request -> service ->
> response
>
> which sucks because this "adapter" is a bad hack!
>
> The next servlet API will include something like this
>
> request -> [ filter -> filter -> filter ] -> response
>
> so it doesn't change the outside servlet model, it's still back
> compatible, but includes an internal modular architecture that can be
> used on both HTTP and Mail servlets for pipelines (see the cocoon
> internals to see what this means in practice and why this is extremely
> useful).
>
> Pier and I both pioneered these approches with mail servlets and cocoon
> architecture on both sides, http and mail. And we are close to include
> this into the servlet spec.
>
> I say: let's not stop now.
You're right: DON'T STOP NOW!
>
> --
> 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]
