cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject [C2.1] Proposal: Cocoon Plumbing Rearchitecture
Date Fri, 08 Jun 2001 20:55:09 GMT
Due to the high complexity of Cocoon 2, and that its internal structure
grew up very quickly, there are IMHO some places where Cocoon 2.1 can
right the wrongs done.  Part of the problem has to do with the fact
that Avalon Framework and Cocoon 2 grew up together.  Both are stable,
and the contracts in Avalon are well understood now.  RSN, the Avalon
project will have some useful documentation on their site (I am still
working on my paper that I will adapt to the site) so everyone will
be on the same page.

The major part of Cocoon's plumbing that can use a major overhaul is
the CompiledComponent infrastructure.  I think that there is opportunity
for a "clean room" reimplementation that takes advantage of our current
model.  I have a sequence diagram of Cocoon 2's processing path, that
I will make available in my developer's web page
( in WMF and possibly GIF.  It shows
just how incredibly complex processing just one request is.  It is amazing
that Cocoon is as fast as it is.

I am working on upgrading Avalon Excalibur's Component Management
infrastructure.  The upgrade will allow us to specify multiple loggers
in the configuration file, and the Excalibur Component package will
set each Component's logger with the specific one we want.  This will
help in debugging--allowing us to have fine-grained control.

The other (more visible) part of the changes have to do with defining
the sitemap and sitemap components.  I want to have Cocoon logically
separate out concern areas for managing a site.  This all has to do
with ease of use, and to keep people from stepping on each other's

I haven't thought through the minutia of the details, so I haven't
found all the devils yet.  Since the types of changes I am proposing
really only affect people who maintain Cocoon (with the exception
of the configuration system), I am interested in hearing other people's

The facts are this: The Sitemap and XSP were architected with very
different designs--and then tried to fit into the ProgramGenerator.
I would like to have one approach, that works for both.

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

View raw message