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
