cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] The next shiny thing?
Date Tue, 06 Dec 2005 13:33:06 GMT
Steven Noels wrote:
> On 06 Dec 2005, at 12:04, Sylvain Wallez wrote:
>> Steven Noels wrote:
>>> On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:
>>>> Struts has Shale
>>> Meeep. Buzzzz. Wrong.
>>> Struts has Craig.
>> And Tapestry has Howard and Spring has Rod. What do you mean?
> I meant to say that Struts is a bad example since it has a benevolent, 
> dedicated person that is cheered upon by a league of grateful 
> groupies, who will follow him anywhere (up to their own imagination's 
> limits). Ditto with Tapestry and Spring and RoR. With Cocoon, there's 
> as much direction as there's developers, and users even: it's big and 
> bloated and lacks direction. And I honestly believe it's the community 
> and consensus tax which make it virtually impossible to create such a 
> unified direction. So so far, I believe we're about to say the same 
> thing, except that I'm pessimistic (as usual).

Ok. Got it. Also, after hitting "send", I realized that I should have 
added "and Daisy has Bruno".

> But you sniped away what I really meant to say, actually. That blocks 
> and interfaces, however they come to into existence, are needed - not 
> only for technical but mostly for community reasons: to provide 
> non-community-shepherded code with its own release and life cycle. To 
> provide users with something they can rely upon. Not the next cool 
> thing down the road, or an experimentation platform for non-enduring 
> geeks. Or a code graveyard for a bunch of consultants.

I wholeheartedly agree. The purpose of layering Cocoon is about ensuring 
strength of contracts. Someone that knows a piece of software inside out 
doesn't need contracts. But others do.

This is the well-known architecture of participation ([1] -- funny to 
see who's quoted) that says that successful communities keep a center 
cathedral around which the bazaar can develop. Lately, Cocoon has failed 
to maintain this cathedral which has been slowly invaded by the bazaar.

Defining contracts in separate modules, and defending them fiercely 
through human oversight and automated tools is a way to help the very 
decentralized Cocoon community to preserve the central cathedral. The 
document I added to Daisy has a chapter dedicated do development rules, 
which is new here.

> I fail to see how giving something fancy names will change that model.

Fancy names are meant to show that something different is going on. 
Technically different, but also more importantly culturally different. 
And that last point is certainly a more difficult change. Some will like 
it, others won't.

> So consequentially, maybe it's the community that needs to change.

It a least must change the way it handles what it produces and how it 

> I'm surprised to finally see evidence of an anti-OSGI camp in Cocoon. 
> Not that this surprises me, but it's just sad that this hasn't been 
> clarified much earlier.

It's not an anti-OSGi camp, but a "are blocks really the solution?" 
camp. OSGi was brought to the picture because no one could agree on the 
kernel/container to use. So we fetched a great ready-made container outside.

> That damned community tax again, I guess. Waste of time and energy for 
> everyone.

Maybe. But that community also has been able to produce many great 
things. Let's try to build this cathedral so that the community bazaar 
can builds even greater things around it.



Sylvain Wallez                        Anyware Technologies           
Apache Software Foundation Member     Research & Technology Director

View raw message