cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [RT] On building on stone
Date Tue, 23 Mar 2004 13:25:30 GMT
I want Cocoon to last long and to be able to stand the pressure of a big 
user community, a diverse development community and that of companies 
built on top of it.

For this reason, we must identify in advance all moves that lead to 
making the cocoon project weaker.

There are three things that provide foundation for a project:

  1) its technology
  2) its community
  3) its license

The three things are not so unrelated as some people think, but this is 
not the topic for today.

Gump indicates that Cocoon has 205 dependencies on external projects. 
Gump has been able to do a clean cocoon run only *once* in its entire 
three-years-long existance.

This is not good. It shows that we are building on sand.

There are two ways to get out of this:

  1) better modularity (to reduce dependencies)
  2) more solid dependencies for our core (to increase solidity of our 
foundations)

As for better modularity, we designed the Cocoon Blocks.

We now have to finish #2.

                                 - 0 -

I've been helping Pier write a block-like container for his employer and 
found out that no matter how hard we try, the Avalon interfaces cannot 
allow to implement Cocoon Blocks the way we designed them.

In short: if we want to have hot-deployable, polymorphically dependent 
high-level cocoon web application components, we can't use Avalon4.

                                 - o -

This leads to a rather difficult choice:

  1) avoid implementing real blocks
  2) change our foundation framework

I would go for #2, since I consider real blocks vital for the evolution 
of this project.

Now, if we go #2 there are three choices:

  1) patch avalon
  2) change framework
  3) do our own

Here my choice would not be technologically driven but rather socially 
driven: I would do our own.

Why? because Avalon's communities are not healthy. The turnover rate is 
incredily high and the burn-out period is amazingly short. Its simply 
too fragile to build cocoon on something like this.

 From a community perspective, Avalon is sand. Avalon's biggest problem 
is that technology is more important than the community. Purity that 
leads to forks is more important than compromises that keep the 
community together.

This is such a strong cultural clash which impact was for long 
underestimated.

Not so anymore and since now we need to make a choice, my choice would 
be to design our own framework and container.

                                - o -

So, here is my detailed proposal:

  1) implement our own framework and container in order to implement 
cocoon blocks [this creates the solid foundation that we control]

  2) create an avalon emulation layer for the legacy components that 
would allow avalon components to run unmodified [this allows users to 
have a smooth migration path and no immediate impact on their 
development/mainteinance costs]

  3) operate as incrementally as possible and work to change as little 
code as possible [this makes the community transition smoother, reduces 
enthropy and bugs introduced by the new code]

  4) keep the framework and container *MINIMAL* to our own needs. [we 
WILL NOT redistribute the framework independently]

  5) the name for our framework+container will be simply Cocoon Core

  6) I volunteer to help directly in writing code

                                 - 0 -

Now, before everybody and their dog replies to this and wishes to 
convince us to use their framework, the only measure of judgement would 
nto be technological but community and its culture.

Cocoon needs a rock solid core.

Solid in both technical, social and legal way.

I believe that social and legal solidity build technical one. The 
opposite is not true. Cocoon and Avalon (both highly considered from a 
technical perspective) demonstrate this pretty well.

I see no potential cocoon core out there that is not a one-man show and 
that allows us to do what we want to achieve with real blocks.

Thus the proposal to write and maintain our own, in order to finally, 
once and for all, build on stone and escape the social quicksands in 
core depenendies.

Fire at will: I have my abstesto underwear on.

-- 
Stefano.



Mime
View raw message