cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject Re: [RT] The next shiny thing?
Date Tue, 06 Dec 2005 10:18:21 GMT
On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:

> Struts has Shale

Meeep. Buzzzz. Wrong.

Struts has Craig.

It's a telltale of Cocoon's problem that we're off discussing marketing  
techniques and branding again, without having any design, code, nor  
dedication to boot with. A busy thread just in time for ACon.  
Currently, I see more community than project in Cocoon.

I'm game for any sort of progress, as long as:

* there's a core set of functionality which is documented through  
maintained API (or conventions) and scripture
* there's a mechanism which enables us to separate the unmaintained  
one-off's aka blocks into separate release and deprecation cycles
* there's more than one actual coder who actually lives through this  
until the end

Maybe this might show people something. This is the reality of someone  
building an application (Daisy) with a UI using Cocoon:

#include.block.batik=false
#include.block.fop=false
#include.block.ajax=false
#include.block.apples=false
#include.block.forms=false
#include.block.serializers=false

, with ajax currently only being included since forms apparently depend  
on it. And Batik is just there to render images in FOP. That's all.

Furthermore, in  
http://svn.cocoondev.org/viewsvn/trunk/daisy/applications/daisywiki/ 
frontend/src/cocoon/webapp/daisy/sitemap.xmap:

org.outerj.daisy.frontend.QueryGenerator
org.outerj.daisy.frontend.ErrorGenerator

org.outerj.daisy.frontend.DaisyLinkTransformer
org.outerj.daisy.frontend.FopImageSrcTransformer
org.outerj.daisy.frontend.TableHelperTransformer
org.outerj.daisy.frontend.IncludePreparedDocumentsTransformer
org.outerj.daisy.frontend.ExternalIncludeTransformer
org.outerj.daisy.frontend.PublisherTransformer
org.outerj.daisy.frontend.IDAbsolutizerTransformer
org.outerj.daisy.frontend.SerializeTransformer
org.outerj.daisy.frontend.CrossRefParserTransformer

org.outerj.daisy.repository.DocumentReadDeniedException
org.outerj.daisy.repository.DocumentNotFoundException
org.outerj.daisy.repository.DocumentVariantNotFoundException
org.outerj.daisy.frontend.util.HttpMethodNotAllowedException

org.outerj.daisy.frontend.SetRequestAttributeAction
org.outerj.daisy.frontend.LocaleAction
org.outerj.daisy.frontend.MountPointAction
org.outerj.daisy.frontend.InitSkinAction
org.outerj.daisy.frontend.SkinsDirAction
org.outerj.daisy.frontend.HandleSiteAction

org.outerj.daisy.frontend.PartReader
org.outerj.daisy.frontend.components.reading.CachingReader

Looking at that sitemap and the tiny list of used blocks, I see a  
number of things:

* there's a need for solid programming interfaces in Cocoon
* there's lots of stuff we don't use

Maybe, when we start from scratch, building solid interfaces, throwing  
away undermaintained legacy, this is a good time to reinvent Cocoon  
into a workable environment again. But IMNSHO, we'll never get there  
with the current approach, effort and dedication. It's the amount of  
community and legacy tax that is putting innovation efforts into  
starvation.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought                              Open Source Java & XML
stevenn at outerthought.org                stevenn at apache.org


Mime
View raw message