Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F4F3831.2060209@student.tuwien.ac.at>
Date: Fri, 29 Aug 2003 13:25:37 +0200
From: Andreas Hochsteger <e9625392@student.tuwien.ac.at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT;
 rv:1.4) Gecko/20030612
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Cocoon Distro support
References: <3385.202.187.40.8.1062137538.squirrel@www.hedhman.org>
In-Reply-To: <3385.202.187.40.8.1062137538.squirrel@www.hedhman.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

You've read my mind, didn't you? ;-)

Seriously, I think you've brought many things down to the point.
Specifically the security issues you've mentioned were given too less 
attention before.

Good work, I like it!

-- Andreas

Niclas Hedhman wrote:

> Hi all,
> 
> the recent comments about production build and "binary builds" have
> caused me to think about Cocoon Distros and what must core Cocoon do
> to allow for Cocoon Distros from 3rd parties.
> 
> Since this overlap quite a degree with the average Cocoon user's
> need of "upgrade running systems", I think it is desirable to start
> a discussion.
> 
> Currently I see these hurdles;
> * Block Modularization.
> * cocoon.xconf Management
> * Sitemap Management.
> 
> 
> Block Modularization.
> This is an on-going effort, but I have a few things I would like to
> clarify.
> Blocks are NOT ONLY CODE! IMHO, Blocks are the traditional JAR based
> resources (classes, bundles, etc), but more importantly(!)
> documentation of the block, meta-data (see Avalon discussions),
> examples, source code (optional) and so on. And all of that should
> be wrapped in a single "container"...
> That container should be "sealed" and I shouldn't need to know
> anything about the internal content, and if Cocoon needs to expand
> it, it can do so anywhere with my knowledge about it.
> Internally there is a default configuration file, but by putting an
> external config file at the same place, it will override the
> defaults, preferably merged.
> Security is another concern. Do I trust any blocks? NO, therefor the
> security policy is declared per block externally, but the default in
> Cocoon should be pretty restrictive (like no write or network
> permissions).
> 
> cocoon.xconf
> Once the Block Modularization is in place, it will have addressed
> these aspects, and very little I hope will remain in this file.
> So if all Block related stuff is removed, and we are down to Core
> funcationality, I think a Distro maker can handle this file fairly
> easily.
> 
> Sitemap Management
> I would like to see a minimalistic sitemap, basically only
> containing the "AutoMount" of all directories' sub-sitemaps.
> The question is whether the component declarations should be in the
> main sitemap or not. I think maybe not.
> The main argument here is "Start simple, expand on demand". The
> elaborate main sitemap today can still be around as a sub-sitemap in
> the "elaborate/" directory...
> Block Modularization probably need to address sitemap declarations
> as well, with a formal way of defaults being added automatically and
> other sitemap declaration should perhaps be adjacent to the Block
> and not to the sitemap, after all keeping the Block stuff at the
> Block makes more sense to me.
> 
> 
> Bottom line; Cocoon is about to broken into smaller, more managable
> pieces. This will easier allow 3rd parties to package Cocoon into
> nice binary distros.
> 
> 
> Comments?
> 
> Niclas
>