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.
> 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.
> 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.
--
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]
