From dev-return-49042-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Thu Oct 09 19:37:02 2003 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 73801 invoked from network); 9 Oct 2003 19:37:01 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 9 Oct 2003 19:37:00 -0000 Received: (qmail 62862 invoked by uid 500); 9 Oct 2003 19:36:46 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 62805 invoked by uid 500); 9 Oct 2003 19:36:45 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 62792 invoked from network); 9 Oct 2003 19:36:45 -0000 Received: from unknown (HELO stud4.tuwien.ac.at) (193.170.75.21) by daedalus.apache.org with SMTP; 9 Oct 2003 19:36:45 -0000 Received: from student.tuwien.ac.at (chello212186106081.14.tuwien.teleweb.at [212.186.106.81]) by stud4.tuwien.ac.at (8.9.3 (PHNE_28809+JAGae91741+JAGae92668)/8.9.3) with ESMTP id VAA24251 for ; Thu, 9 Oct 2003 21:36:49 +0200 (METDST) Message-ID: <3F85B8CF.2010901@student.tuwien.ac.at> Date: Thu, 09 Oct 2003 21:36:47 +0200 From: Andreas Hochsteger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.4) Gecko/20030612 X-Accept-Language: de-at, de, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] Finishing the first phase of block design References: <34148790-FA5B-11D7-877F-000393D2CB02@apache.org> In-Reply-To: <34148790-FA5B-11D7-877F-000393D2CB02@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Stefano Mazzocchi wrote: >> - Will not explicitly declaring which resources are meant to be public >> cause trouble for block implementors and extenders? > > > ?? well, in the sitemap I can be very precise on what I want to expose. > and everything else is not exposed. the sitemap is like a virtual file > system description, powerful enough to describe all possible systems. > > If you have > > > > > > > > than the contract moves at the file system level, but that's up to you > to decide.... and a block extender can do > > > > > > > > > > to provide extension that is procedural (but without exposing, for > example layout.xml and layout2stylesheet.xslt which are just used > internally) > > With a single mechanism, it's much easier to do meaningful block extension. > >> Of course the flexibility of decoupling the uri space from the >> filesystem is a benefit - but is it necessary? > > > see above: I think so. > >> How hard is it really to keep filenames and directory locations for a >> selected group of public resources? > > > no, that's not the issue: the real issue is: if both resources and > pipeline outputs are streams, why make a difference? > I agree with Stefano at this point. The independence of the physical filesystem layout is one of the best features of Cocoon and it wouldn't be good to loose this great concept for blocks. > -- > Stefano. > Bye, Andreas