cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <p...@apache.org>
Subject Re: servlet or no? (was Re: [Moving on] SAX vs. DOM part II)
Date Mon, 24 Jan 2000 20:51:29 GMT
brian moseley wrote:
> 
> On Mon, 24 Jan 2000, Pierpaolo Fumagalli wrote:
> 
> > I perfectly agree how XSLT can work off line, it's just
> > a transformation language... But, regarding XSP, I don't
> > think this is a possibility... It's like trying to run a
> > CGI from the command line...
> 
> i think we're talking about two slightly different things,
> and this may be due to my incomplete knowledge of xsp.
> 
> doesnt the xsp "processor" compile logicsheets into java
> classes? aren't those cached? or isn't this at least the
> plan? this effort is the one i'm referring to with regards
> to offline operation.

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?

> > Hey... Let's remember one thing... some components ARE
> > reusable (serializers: FOP, XML/HTML printers, NRG
> > engine... and filters like XSLT) some are tied to HTTP
> > (XSP, things that rely on POST)...
> 
> the execution of logic happens at request time. compilation
> should not be forced to happen at request time.

Totally... Compilation could  be even done off line, then kicked into a
nice JAR file and loaded by cocoon... That's not a problem... That's
CACHING, or preprocessing... I thought we were talking about letting XSP
do the EMail job.

> > I'm not saying that the whole universe NEEDS to be tied
> > to HTTP, but I say that in the context of Cocoon, it
> > would be overhelming allowing it to deal with things
> > like EMails, and that it would be better if we restrict
> > it to Web Sites.
> 
> i have never heard any details about why people are so
> scared of using a servlet request that contains a mime
> structure. i don't think anybody is talking in the cocoon
> context at least about writing an smtp servlet.

That was the idea... Using cocoon to deal with Email... That's the point
that started the whole discussion...

> consider this use case: procmail pipes an email message
> to a command line tool. the tool creates a servlet request
> out of the message and hands the request to the cocoon
> engine. the engine creates a servlet response containing an
> html document. the tool places the html document on
> the file system and checks the file into cvs.

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.

> i have a hand coded perl tool that does something exactly
> like this. if cocoon was a bit more flexible, i could use it
> instead.

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

> > Other tools based on the same components (same pieces,
> > different glue) can be created to generate E-Mail, to do
> > gopher, to create XML->LDAP servers, or whatever we
> > want, but those SHOULD NOT USE the same glue used for
> > the Web. The WEB-GLUE is cocoon...
> 
> disagree. the sitemap and the http interface are web glue.
> the rest of cocoon is not. producers, processors,
> formatters, serializers, those do not have to be web
> specific in any way.

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

<joking>
Or not? I'm starting to loose my credo... I want a religion to follow...
Please someone summon me now :) (read it, Stefano, where are you?)
</joking>

	Pier (not following anymore the point of the discussion)

-- 
--------------------------------------------------------------------
-          P              I              E              R          -
stable structure erected over water to allow the docking of seacraft
<mailto:pier@betaversion.org>    <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------

Mime
View raw message