Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 56550 invoked from network); 10 Oct 2003 09:05:14 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 10 Oct 2003 09:05:14 -0000 Received: (qmail 53675 invoked by uid 500); 10 Oct 2003 09:04:44 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 53654 invoked by uid 500); 10 Oct 2003 09:04:43 -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 53640 invoked from network); 10 Oct 2003 09:04:43 -0000 Received: from unknown (HELO vern.chem.tu-berlin.de) (130.149.66.116) by daedalus.apache.org with SMTP; 10 Oct 2003 09:04:43 -0000 Received: from vern.chem.tu-berlin.de (localhost [127.0.0.1]) by vern.chem.tu-berlin.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h9A94t6r005195 for ; Fri, 10 Oct 2003 11:04:55 +0200 Received: from localhost (stephan@localhost) by vern.chem.tu-berlin.de (8.12.3/8.12.3/Submit) with ESMTP id h9A94sjq005192 for ; Fri, 10 Oct 2003 11:04:54 +0200 X-Authentication-Warning: vern.chem.tu-berlin.de: stephan owned process doing -bs Date: Fri, 10 Oct 2003 11:04:54 +0200 (CEST) From: Stephan Michels X-X-Sender: stephan@vern.chem.tu-berlin.de To: dev@cocoon.apache.org Subject: Re: [RT] Finishing the first phase of block design In-Reply-To: <34148790-FA5B-11D7-877F-000393D2CB02@apache.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 9 Oct 2003, Stefano Mazzocchi wrote: > > On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote: > > > Stefano Mazzocchi wrote: > > > >> I have updated the block design documents on the wiki. Changes were: > > > > ... > > > >> A few things are left to decide: > >> 1) the block metadata information in the block.xml file > >> see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob > >> 2) how blocks expose classloading to other blocks > >> - o - > >> Descriptive Block metadata > >> -------------------------- > >> The descriptive block metadata that we currently include is: > >> *** > >> *** > >> *** > >> *** > > > > +1 > > > > Andreas suggested version number which is really handled already in > > the block id and release date. I think a date though may be a useful > > additional piece of info. > > Good point. IMHO, I would try first a solution, which doesn't introduce a new descriptor. In a know german XML magazin, Cocoon was descriped a configuration hell, and as a anti pattern using XML as configuration format. So my proposal would be to start small, and if there isn't a way to come forward with the current possibilities, then we could introduce a new descriptor file beside cocoon.xconf/sitemap.xmap/web.xml etc. > >> Exposing classes > >> ---------------- > >> Stephen proposed to separate the classes to expose in a different jar > >> and expose that. I like this. It's simple and effective. > >> But instead of declaring classloaders or classpaths in the blocks, I > >> propose to extend the block FS layout so that we have > >> for individual classes and resources: > >> /classes > >> /classes/public > >> /classes/private > >> for jars: > >> /lib > >> /lib/public > >> /lib/private > > > > Hmmm. That is quite different than what one would expect from the WAR > > paradigm, no? Would > > > > COB-INF/[classes|lib] > > COB-INF/public/[classes|lib] > > > > or > > > > COB-INF/private/[classes|lib] > > COB-INF/public/[classes|lib] > > > > be any better? Could you please explain, why we need to separate the classes and lib into private and public. For the developers POV, it will make the development more complicated, and doesn't see any benefit. > > Exposing Resources > > ------------------ > > > > I'm adding this because my brain is still a little unsure about this. > > So far, we've said that file resources (an xsl for example) > > > > 1) need to be exposed via a sitemap pipeline, even if only by a reader > > 2) are not anywhere declared explicitly (except in the pipeline of > > course) > > 3) are not distinguised from resources meant to be private by any > > formal semantics, though this information could be conveyed > > human-to-human in any block docs (blocs? blockumentation? ;) ). > > > > Here are my oustanding questions: > > > > - Will we regret requiring the overhead of pipeline setup (runtime I > > mean) for blocks which expose a great deal of otherwise static > > resources? > > could be. remember though that the block: protocol will be caching > friendly, so we might even gain performance. > > > - Not found resources will have to go through every pipeline to > > determine that it's not found. With fallback behavior due to > > polymorphism this gets worse. > > I fail to see this, can you explain why you think this is the case? > > > - 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) Yes, I like that. This is the solution, which comes first in my mind. Stephan.