cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [RT] On building on stone
Date Tue, 23 Mar 2004 14:19:09 GMT
Stefano Mazzocchi wrote:
> 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.


> 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.

I'd add a parallel reason which may also be understood by people who may be less 
convinced about the health of that community or its importance (alas, I am no 
longer one).  We cannot trust this core to a separate entity who have many other 
needs to consider in parallel.  Why?  We have specific needs, and need them 
quick.  Also, we've found in practice that our container needs don't always have 
a lot of overlap with others' needs.  We are far simpler in some ways, more 
complicated in others.  If in some hypothetical future scenario others share a 
good deal of our needs, we can decide at that time if we should enable others to 
use our core by packaging separately - but I would be surprised if we ever would 
a) want this core managed elsewhere, or b) want to have to answer to users with 
different needs totally unrelated to Cocoon.

> Fire at will: I have my abstesto underwear on.

Hopefully you will not need it.  Your proposal needs to be tested by fire, but 
not you - let's get that out here early.  Personally, knowing that there is 
already some "code on disk" makes this seem very attainable.  If it means we 
have blocks sooner than later, I am 100% behind it.


View raw message