Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 25040 invoked from network); 24 Jan 2000 20:50:48 -0000 Received: from dnai-216-15-97-206.cust.dnai.com (HELO kali.betaversion.org) (216.15.97.206) by 63.211.145.10 with SMTP; 24 Jan 2000 20:50:48 -0000 Received: from apache.org(firewall-95.exoffice.com[207.33.160.95]) (4888 bytes) by kali.betaversion.org via smail with P:esmtp/R:internet/T:smtp (sender: ) id for ; Mon, 24 Jan 2000 12:50:53 -0800 (PST) (Smail-3.2.0.106 1999-Mar-31 #3 built 1999-Sep-21) Message-ID: <388CBB51.AFA9C8A9@apache.org> Date: Mon, 24 Jan 2000 12:51:29 -0800 From: Pierpaolo Fumagalli Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: servlet or no? (was Re: [Moving on] SAX vs. DOM part II) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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... 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?) Pier (not following anymore the point of the discussion) -- -------------------------------------------------------------------- - P I E R - stable structure erected over water to allow the docking of seacraft -------------------------------------------------------------------- - ApacheCON Y2K: Come to the official Apache developers conference - -------------------- --------------------