[RT] Cocoon Distro support

[Niclas Hedhman <ni...@hedhman.org>]

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

Re: [RT] Cocoon Distro support

[Andreas Hochsteger <e9...@student.tuwien.ac.at>]

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
> 

Re: [RT] Cocoon Distro support

[Stefano Mazzocchi <st...@apache.org>]

On Friday, Aug 29, 2003, at 08:12 Europe/Rome, 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.

[snip]

*everything* about ease of distribution, ease of webapp-level 
composability, ease of reuse, ease of configuration, ease of 
deployment, ease of staging, updating, cluster replication and what not 
has *ALREADY* been considered in the block design.

Can people *PLEASE* take a look at that before restarting anew 
everytime?

Thanks.

--
Stefano, frustrated when people base their context on their own 
assumptions instead of reading previous context.