cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Micro kernel based Cocoon
Date Sun, 22 May 2005 18:24:23 GMT
Carsten Ziegeler wrote:

<snip/>
> I'm currently still missing the *big picture*. What are blocks, how does
> Cocoon look like with them. Can I develop something without blocks? What
> do I have to learn? And so on. This might be because I didn't have so
> much time for Cocoon in the last weeks, don't know.

It would require quite a lot of work to give a fair overview of what we 
have discussed about this in the last three or so years. You find some 
info in http://wiki.apache.org/cocoon/Blocks. And for the relation to 
OSGi I suggest that you reread my first post in this thread together 
with some of the references.

I can give a short overview on how I currently view what Cocoon would 
look like if we go the OSGi bundle way.

All current blocks, the core and libraries that are used by several 
bundles are packaged as bundles. These are deployed in a OSGi kernel. 
During development the Cocoon bundles can be deployed within the OSGi 
kernel of Eclipse together with various Cocoon develpment plugins 
(bundles). And during deployment the Cocoon bundles are deployed in a 
standalone kernel that either is started from within an servlet or at 
"top level" and contains a http server.

The OSGi kernel is like an OS kernel. It takes care about starting and 
stoping bundles and to resolve dependencies between bundles and gives 
them a parent classloader containing their dependencies.

The above means that we can get a much higher level of isolation beween 
different parts of core and between blocks. As the bundles don't need to 
expose all classes to everyone anymore. This is something that we 
allready need quite badly IMO, and a must if we wish to make it possible 
for external communities to develp Cocoon blocks.

Having this means that a user can download a minimal Cocoon disto with 
some core bundles and a bundle (block) management utility. This can then 
be used for download and deploy the rest of the bundles that the user need.

I also think that the current core should be splited in a number of 
bundles. I would like to have a Cocoon core bundle that contains the 
tree processor, the component manager and core interfaces. The Cocoon 
core will define what Cocoon is. It will have an own release cycle like 
an OS kernel. And the stable release should be rock stable. The servlet 
and CLI environments should be own bundles. The flowscripts could be an 
own bundle. Most of the components in current core could be transfered 
to own bundles.

By breaking up todays monolitic core we are able to deprecate things 
that we don't believe in anymore and move to an own bundles that still 
will make the functionality available for those depending on it, 
whithout making core bloated.

                     --- o0o ---

Above this we have the "sitemap aspect" of blocks. Its more at the 
application level and doesn't have much to do with our current blocks. 
It is more for creating reusable application frameworks. It will be 
usefull for projects like Forrest, Lenya, Daisy, Linotype and probably 
for Portal. It gives you a possiblity to create bundles that not only 
exposes components and can contain own components, but also make sitemap 
functionality available through the block protocol.

/Daniel

Mime
View raw message