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: trunk light (was [RT] A new Forrest implementation?)
Date Tue, 22 Aug 2006 10:09:52 GMT
Thorsten Scherler skrev:
> Hi all,
>
> http://marc.theaimsgroup.com/?t=115558565300001&r=1&w=2
>
> I know we had the light/diet discussion many times but the forrest
> community has an emerging need for a very small cocoon. The forrest
> community is talking about a new forrest implementation that is not
> based on cocoon anymore. This is because we feel that we do not need
> *all* the features that cocoon provides to reduce the complexity of the
> forrest code it seems that the community would like to drop cocoon or
> alternatively slim it down close to the cocoon 1.x features.
>   
Most Cocoon users and developers doesn't need all of Cocoon either. With 
the Maven build it is much easier to handle dependencies and just depend 
on what is needed. Still some of the blocks, especially the core, are 
still far to bloated.
> Like Bertrand suggested in the above thread we need basically:
> "So, a "Cocoon light" version that does just the following might be
> fairly popular among this category of users:
>
> -Sitemap-based XML processing pipelines
> -XSLT transformers
> -Pluggable custom Java transformers
> -Aggregation using the cocoon:/ protocol"
>
> How could both community work together to get a light version. 
>   
We have discussed splitting up the core a number of times. The idea is 
basically moving out as much as possible to own blocks. We have already 
moved out the CLI to an own block (don't know if it works though). We 
are working on simplifying component management by following Spring 
practices as far as possible. Ideally component management shouldn't be 
a Cocoon development concern anymore, we should just use what the 
container offers. Other things that could be moved to own blocks are:

* The flowscript implementation
* The sitemap components
* Most of the other components (sources, input/output modules etc)

Exactly what blocks we should create for the components in the core is 
an open question. AFAIK we have not discussed if there are any natural 
categories for the components.

Anyway, it shouldn't be any rocket science to move out components from 
the core. It is basically just to start doing it and ask on the list as 
the work continues.

/Daniel


Mime
View raw message