cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From brian moseley ...@maz.org>
Subject Re: servlet or no? (was Re: [Moving on] SAX vs. DOM part II)
Date Mon, 24 Jan 2000 21:05:09 GMT
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.

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

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

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

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

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.

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


Mime
View raw message