Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 39972 invoked by uid 500); 2 Nov 2001 10:04:11 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 39961 invoked from network); 2 Nov 2001 10:04:10 -0000 Sender: ulim@denic.de Message-ID: <3BE26F96.ED4B3F55@denic.de> Date: Fri, 02 Nov 2001 11:04:06 +0100 From: Ulrich Mayring X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [RT] Integrating Cocoon with WebDAV References: <3BDF56E0.1010404@hartle-klug.com> <3BE05E89.F8972C42@apache.org> <3BE26691.1000909@rabellino.it> X-MIMETrack: Itemize by SMTP Server on notes/Denic(Release 5.0.6a |January 17, 2001) at 02.11.2001 11:03:52, Serialize by Router on notes/Denic(Release 5.0.6a |January 17, 2001) at 02.11.2001 11:03:53, Serialize complete at 02.11.2001 11:03:53 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Gianugo Rabellino wrote: > > Cocoon > looks to me as the crypt() functions: a perfect, robust and stable > system with the feature or limitation of being almost totally "one way". Plus, Cocoon is too monolithic. It's developed with the Avalon framework, but it can't run under Phoenix. It's not made up of a set of components (blocks) that can be combined freely. I can't just run Cocoon without the Sitemap or swap the Sitemap with my own scheme. For example, 95% of what I need is a block that does XML-->XSL(FO|T). I have many server-side apps, who would love to use this block. Why should they make a costly HTTP connection to some server that runs Cocoon and commit to the interfaces Cocoon prescribes? Wouldn't it be much cooler if I used the "XML-->XSL(FO|T)" block from Cocoon and keep everything within the framework and on the same JVM? I could even run a HTTP/Servlet server under Phoenix (e.g. Jo!) and have it use Cocoon's blocks for doing XML stuff - no costly TCP connections to some servlet engine anymore. So, my belief is that Cocoon must be componentized, before complex things like content management or workflow become possible. If the Sitemap would bother you in a WebDAV workflow, you could just take it out. It would become easy to bypass troublesome generators and get at "the pure XML source". > but I'd rather see a CMS (or, even better, a CMS framework) written from > scratch *using* Cocoon that generally enabling any Cocoon to > transparently edit content. Components is the magic word :) Ulrich -- Ulrich Mayring DENIC eG, Systementwicklung --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org