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