cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <>
Subject Re: servlet or no? (was Re: [Moving on] SAX vs. DOM part II)
Date Mon, 24 Jan 2000 23:13:50 GMT
brian moseley wrote:
> On Mon, 24 Jan 2000, Pierpaolo Fumagalli wrote:
> > Are we talking about CACHING the XSP (the class file
> > produced...) or we're talking about executing XSP
> > gathering request (and response) informations from an
> > E-Mail?
> i don't think of it as caching. in my deployment scenario
> the application never adds or removes compiled classes. it
> only loads them, and reloads them when it notices they have
> changed on disk.
> from the point of view of the offline compiler, you might
> consider it a cache.
> either way, we are certainly not talking about executing the
> logic in response to an http request, or any other kind of
> request.

So, when do you execute the logic? I'm starting to loose focus.

> > That was the idea... Using cocoon to deal with Email...
> > That's the point that started the whole discussion...
> the tool i described "deals with email" just as an smtp
> server "deals with email". their suitability for embedding
> cocoon is somewhat different.

????????????????? I don't REALLY follow...

> > That's cool... as long as cocoon receives an HTTP
> > request and response, I'm totally +1 on it... It's your
> > business, then, to correctly translate the EMail into
> > some HTTP stuff.
> not what i was going for.

But the SMTP and HTTP models ARE orthogonal.. How can you reconcile
those? SMTP doesnt' provide a request-response mechanism, while HTTP

> > You can write a java class that takes an EMail, converts
> > it into a ServletRequest/Response, place it in cocoon
> > and let it go, that would make the trick, but, SERVLETS
> > are not EMAIL...
> i didn't say they are. smtp and http are equivalent
> transport mechanisms for mime data.

But their operation model IS different.

> i agree that servlets are not the best way to implement an
> smtp server.

Cool :) at least on this we agree...

> i disagree that there can not be servlet request and
> response subclasses that provide methods for accessing
> standard rfc822 and mime email headers. these methods would
> probably be very similar to those on the javamail message
> class.

I like this guy... He reminds me of another guy I knew around october
1998 when he, with a friend, invented a thing called Mail Servlet... :)

> > YES... So, we're saying the same exact thing... Don't
> > reuse the GLUE, reuse the PIECES... Cocoon IS the http
> > interface (AKA servlet) AND the Sitemap... I thought
> > there were NO DOUBTS on that... Let's not confuse Cocoon
> > with a tool that applies stylesheets to XML, please,
> > Cocoon is more than that...
> no, i don't think we're saying the same exact thing. if you
> define cocoon as the http interface, then you really should
> define the producer/processor/serializer engine as something
> else. that can receive and respond to more transports than
> simply http. otherwise you are limiting your user base.

The producer/processor/serializer interfaces are not (yet) defined. I
would make them as similar as possible to servlets (the data required
inside, IMVHO, is ServletContext, HTTPServletRequest and
HTTPServletResponse). But if you want to come up with a different
paradigm of request/response model that can be also used from James (or
whater email server), I will be more than happy to discuss it.
Then Cocoon will be a bridge between the servlet world to this new
world... And GiveANameHere, could be the bridge between EMail and it...

	Pier (who already feels he's going to throw in the trashbin
              two weeks of work!)

-          P              I              E              R          -
stable structure erected over water to allow the docking of seacraft
<>    <>
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <> --------------------

View raw message