cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [vote] Starting 2.1-dev
Date Wed, 10 Apr 2002 08:10:19 GMT
Stefano Mazzocchi wrote:

>I think it's a good thing to plan the future releases now that we have
>created a maintenance branch for the 2.0.x series.
>I propose the following actions:
> 1) set the version of the trunk as 2.1-dev

+1. Flow engine and sunShine are major new features

>2) set the tree processor as the default pipeline manager (means making
>the interpreted sitemap the default one)

+1, but already done !

>3) merge Schecoon with the main trunk


>4) remove the compiled sitemap implementation from the trunk [this will
>give more stress on the interpreted sitemap implementation as well as
>removing problems associated with the merging of Schecoon]

-0 : I'd like to start by moving the compiled engine out of the 
"sitemap" package so that this package contains only 
implementation-independent classes and interfaces.

The treeprocessor will naturally be stressed as it is the default engine 
(this has already begun and a number of bugs have been fixed).

About Schecoon, once more, the dependency that currently exists on the 
treeprocessor internals will disappear very soon : its link with the 
sitemap will go through the single Redirector interface. Yes, it comes 
with new treeprocessor nodes definitions, but this is just some glue 
code that could easily exist also for another sitemap engine.

> 5) merge the 'sunShine' stuff in the main trunk [one note: I personally
>don't like the use of the term 'sun' so much around there. SunShine,
>Sunlet, SunSpot... I would *strongly* suggest a name change for those
>things, but for sure I like their functionality, even if, in the future,
>they will probably factored out as Cocoon Blocks]

+1. I've seen that Carsten started to refactor some of the sunShine 
internals into the main trunk. This is good, as other applications will 
be able to grow on that stuff.

> 6) decide what is solid enough to be moved in the trunk out of the
>scratchpad [NOTE: for 'solid enough' I don't mean 'implementation wise'
>but 'contract wise']

+1. We should distinguish in scratchpad what belongs to the main source 
trunk, and what are advanced examples. This goes in favor of the 
refactoring of samples that is underway : having all examples in the 
main webapp sitemap frightens newbies (this sitemap is the biggest one 
I've ever seen), and segmentation in subsitemap will allow users to 
learn in progressive steps and concentrate on particular features 
without having to dig through dozens of mixed examples.

> 7) ???
Hey, did you forget Cocoon blocks ?


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message