cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [Proposal] Cocoon Organization
Date Mon, 05 Aug 2002 07:41:15 GMT
Hi everyone,

I also thought about this problem in the last weeks (during some
mountain climbing...) - does anyone remember Stefano's email
about the "thermal death"? If not, search the archive and read it.

Yes, Berin is absolutely right - Cocoon is way too big. And it's
getting bigger and bigger. For usual web applications I guess
you always only need let's say 20% of Cocoon - it's not always
the same parts you need but you will never need everything of
Cocoon at once (ok, never say never, I know).

When we made our donation for the authentication and the portal
framework, I tried to separate them as much as possible. You can
build and use Cocoon without them and later additionally plug
them in. (At least this is the way it should work ;) )

For other "parts" like FOP serialization etc this is also possible.

But what for some "more core areas" like flowmaps or input modules?
And I fear there are other things which only (currently) a minority
really needs (and yes, add the authentication and portal frameworks
to this list).

In the last months the answer to this problem was always: blocks!
So making Cocoon (just) one step complexer makes it more handable
and easier to understand...really? If you look at the problems
the average user of Cocoon has, then you see that most of them
have problems understanding the complexity of Cocoon and getting
simply started. IMHO this can't be solved by just adding another
complexity layer. (This is not a -1 vote for blocks).

Let's have a look at what had happened over the last weeks/months:
several individuals added more and more features, like the authentication
framework, the portal framework, the form handling, the flow maps etc.
Each individual did not really care about the community, he only wanted
to get this cool feature working. And don't get me wrong, this includes
myself. We also started the "documentation project" and we "fought" with
others who claimed about the poor documentation and Cocoon being too
In addition we are getting more and more RTs, patches and bug reports which
all get more or less lost (or again simply add more complexity).

So currently I see us as a very motivated group of individuals all doing
their job (very good by the way) but not considering to act on a more
community base. For example - to not offend others, I take myself as an
example - the portal framework: In order to get it nicely working with
some very cool portal/configuration features, I needed some other new
besides the portal framework in Cocoon. This includes the
RequestLifecycle, the ConfigurableSitemapComponents and some other minor
things. Who of you knows what these concepts are? Did I ask someone, if this
really makes sense? Are they documented well? etc.

Now I think we really did some mistakes (and yes, this again includes
To proof this, here are some questions (and please, they are not meant to be
- Who of the Cocoon community knows how the portal framework works?
- Who of the Cocoon community knows how the authentication framework works?
- What's the status in form handling?
- Do we need input modules?
- Do we have memory leaks?
- Is the caching really working?
- Does Cocoon work with JDK 1.4?
- What has to be done for the next release, 2.0.4 or 2.1?

But the most important question is: who needs all these new features?
Shouldn't we focus on getting a even more stable release and more
documentation instead? Who needs a portal framework inside Cocoon, who needs
input modules and who needs blocks?

Let's take the blocks concept as another example. We have the really great
RT from Stefano and Giacomo, but look how many have responded to it. Do they
not care about blocks? Couldn't they follow the RT? Are blocks really
I personally didn't answer the blocks RT, because I feel that it is not the
concept I (= Individual!) was looking for, but I can't express how it could
be better.
Or flowmaps? What is their use? If I didn't understand the sitemap, how will
I ever learn about flowmaps?

Ok, I know, one answer to this will be, if you don't want to use blocks or
flowmaps, you don't have to. But how does this work? Will we state: "Cocoon
the sitemap, flowmaps and blocks. But don't worry, if this is too
complex for you, just use only the sitemap and forget about the others, you
need them...". Well...

Many users already claim, Cocoon is too complex. And we say: it will get
easier, because we add more cool features, like a portal framework, flowmaps
and blocks to it! Now, I don't believe this and I fear the usual user will
not believe this, too.
Stefano already pointed at this in his thread about the "termal death of
When he wrote that, I thought, "hmm, perhaps he's right - perhaps not, ah
how can I get this authentication thing working, hm, let's see..." - Now I
he is right - if we go on following this road, I promise, we will have a
death of Cocoon more sooner than later. And I think, the current blocks
discussion does not help in this aspect.

So what can we do about it? Try to act more like a team and let's more
to the user needs. The documentation effort is one step in this direction,
personally I think there is a problem there, too. New documentation features
are currently delayed until forrest is ready! So, instead of focusing on the
real problem, a new construction area has been build up (forrest) which has
to be
completed beforehand! This is not very helpfull.

But let's come back, to what we can do.
First of all, a feature stop! I don't mean an RT stop.

Second, thinking of SoC (ok, perhaps not the right context to use this
term) - we should try to build a minimal Cocoon or core Cocoon if you prefer
and put everything else into additional modules (read: not blocks). By
modules I simply mean different directories in the CVS in order to
optionally build them. Let's remove the authentication framework from the
core, the form handling, the input modules, the flow map, the fop serializer
etc - simply everything which is not necessary to run Cocoon.

Third, let's identify the issues for the upcomming releases.

Fourth, let's search for volunteers for the open issues, for bug fixing and
for testing!

Fifth, discuss the available patches and open RTs and make proposal
documents out of them.

Or putting it in other words: Let's not forget the users needs over all
this cool new features and RTs.

Now, I'm pretty sure, that some might now stand up and say: "Hey, Carsten,
you know what? Cocoon is open source, so if you see a need, you can
contribute and fix it." Well, that's the individual approach we were
following in the last months. And does it really work? Or someone will
say "Hey, it's alpha, what do you expect?"...

And one final note:
Just do a simple performance test: create a pipeline reading an xml file
transform this in two steps with two xslt transformers and serialize it
to html (or xml if you want). Do a stress test on the same machine
using Cocoon 2.0, 2.0.1, 2.0.2, 2.0.3 and 2.1-dev. (I don't know
the answer to this test, but I would bet a book on the result).

So, whew, you see I had some time to prepare this email...and now
the flame-war can begin...

But summarizing this: +1 on Berins idea.


Berin Loritsch wrote:
> Currently Cocoon is 1.5 MB in size.  That is a huge jar.  In Cocoon
> there
> are the core files, the servlet compatibility files, the CLI
> compatibility
> files, and hundreds of components.
> The fact that we as a community are thriving is excellent.  However, as
> a
> project, Cocoon is feeling quite heavy.  Esp. since there are features
> in
> Cocoon that not everyone needs.  I proposed this a while back, but I am
> going to propose it again.
> We should split Cocoon into core development and component development
> efforts, much like Avalon does with Framework and Excalibur.  That will
> allow the components to be packaged in jars that serve a similar
> purpose.
> Things like all the database related components should be in their own
> mini-project.  Each mini-project has its own documentation, and its own
> life.  It also allows each mini-project to determine whether it is ready
> for prime-time or not.  At every release, the core cocoon does not have
> to worry about which components it has to move into scratchpad.  Also
> each set of components has a little focused mini-community so the docs
> get upgraded in a focused manner.
> I have already seen the benefits of how this works in Excalibur--now
> that
> we are going through systematically.
> When I am generating a site, I don't want to have to include the portal
> components or the DB and auth components.  Those don't need to be there
> for the site.
> Keep in mind that the mini-projects are all part of the cocoon umbrella,
> and they foster functioning communities within the larger Cocoon
> community,
> not detract from it.
> "They that give up essential liberty to obtain a little temporary safety
>  deserve neither liberty nor safety."
>                 - Benjamin Franklin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

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

View raw message