cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject [RT] Cocoon Distro support
Date Fri, 29 Aug 2003 06:12:18 GMT

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



Mime
View raw message