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 20:31:06 GMT
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.

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

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

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.

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.

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


Mime
View raw message