cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: [STATUS] architecture design
Date Mon, 29 Oct 2001 07:37:18 GMT
On Sun, 28 Oct 2001, Stefano Mazzocchi wrote:

> giacomo wrote:
> > Sometimes it is good if you have pressure from real work which suck time
> > you'd like to give to OS projects. Afterwards you'll usually have new
> > power and ideas to rejoin the community. I speak from experience and I
> > also think Stefano can confirm it ;)
> Absolutely, dude! :)
> Ok, Giacomo raised the issue again and it's time to do something to
> resolve something and decide where we are going.
> So, from now on, we can use the [STATUS] in mail messages to indicate
> summaries that allow people to keep up.
> Status files should be simple and selfcontained so that everybody can
> grasp it without having to read thousand lines of RT or mail digests.
> So, here we go.
>                                 - o -
> There are three main areas that require architectural changes:
>  1) pipeline assembly and control
>  2) dynamic XML production
>  3) deployment of cocoon-powered sites and web applications
> Pipeline assembly and control
> -----------------------------
> The first area is currently covered by the sitemap that includes
> instructions on how to define components, assemble the pipelines and
> control their operations.
> A few limitations were observed:
> a) it mixes concerns: it is hardly possible for a non-programmer to
> become a sitemap designer/maintainer.

This is IMHO the main problem

> b) flow isn't obvious: the sitemap was designed around a request
> matching paradigm which is great for publishing but fails short for more
> complex web applications.


> c) the use of code generation and compilation increases load time and is
> believed not to increase runtime performance due to hotspot removal.

There are other reasons for eliminating code generation and compilation
like complexity which the javac imposes, or easier reloading strategies.

> d) mostly due to c) and further implementation details, sitemaps cannot
> be cleanly nested and components inherited.

Well, this is due to the existance of the CodeFactory interface which
IIRC is eliminated in the HEAD branch.

> Possible solutions to the above problems were proposed:
> 1) avoid code generation and aim to fast tree-traversal algorithms. It
> is likely to increase memory use but it would remove both c) and d)
> problems.

+1 This doesn't mean that I've changed my mind in regards of rewriting
the current sitemap semantics from a currently compiled into a
interpreted one. Sure, I wouldn't stop any volunteer doing so but my
vote on this will be -0.

> 2) two proposals were submitted along the very rough "flowmap" concept
> that Stefano outlined some months ago. They are:
>  a) Berin's [fixme - indicate mail URL]
>  b) Daniela's and others at [fixme - indicate mail URL]
> The two solutions aim both to solve both a) and b) and make it easier to
> use Cocoon to write web applications and to separate the concerns
> actually mixed by the current sitemap design.
> Solution a) is not back compatible and requires semantic changes to the
> sitemap while solution b) is back compatible and may be added today.

I don't prefer either one. The proposal from Berin is IMHO a new
approach and will have another learning curve than the on from Daniela,
which I've grasp immediately (more or less :)

> Possible direction would be to let volunteers implement solution b) to
> earn more information that could be applied to a major new back
> incompatible Cocoon release (maybe 3.0 or so).


> Dynamic XML production
> ----------------------
> Note that I didn't say "generation" because it could happen at both
> generation and transformation stages.
> This part is currently achieved by manual writing of pipeline components
> (generators or transformers) or by the use of XSP or JSP technology, or
> the use of other scripting languages.
> While the solution to manually create components will always remain,
> this is suitable only for ad-hoc solutions that require lots of
> programming logic and very few static content (just like servlet vs.
> JSP, so to speak).
> While the use of JSP or other scripting languages (jpython, PHP) is
> possible, XSP is currently the most advanced solution but, again, it
> mixes concerns.
> Proposals are:
>  - x:forge (
>  - DXML (Ricardo's project)
>  - SAXlets (levigo's project)
> Ok, you guys add more comments if you need to.

There is still some thought in my mind about dbXML (or other XML
DBs) which could result in a new protocol for a Source of XML.


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

View raw message