cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject Re: Orbeon vs Cocoon? - Live version available?
Date Fri, 17 Dec 2004 10:11:44 GMT
On 17 Dec 2004, at 10:13, H.vanderLinden@MI.unimaas.nl wrote:

> It would be nice if there was a place where the latest release would be
> running, so everyone could check it out. I know this requires cleaning 
> up
> the crap that some people think they should enter, but that might be 
> done
> through some simple scripts.
>
> It would also give future users the change to have a look at Cocoon 
> before
> doing the actual download. And newbies can verify if they have done 
> things
> correctly because they can compare their own version with "THE" live
> version.
>
> I know server hosting will be a problem, but maybe it's running 
> somewhere
> already which could be made available to "the world"?

FWIW, this has been running on cocoon.cocoondev.org for more than two 
years, but I pulled it down due to lack of hits. Similarly, I will be 
dropping the webmail.cocoondev.org demo soonish.

I had a Cocoon BOF two days ago at JavaPolis. I spoke to quite a few 
folks during the conference as well, which know how we (as a company) 
have been pushing people to use Cocoon over the past three years.

With all due respect, I think there's only a few things we should care 
to work on to give Cocoon more chances for success. I know there were 
many success stories lately, but we should be realistic as well: the 
world is looking into a shift from Struts to JSF, and that's about all 
they care. People still perceive Cocoon as a big, complicated, scary 
beast.

Some recurring complaints were:

* documentation (oh well)
* cohesive direction (as in: _only_ explain folks about things like the 
power trio, and make sure these things work flawlessly, and stop being 
hesitant about deprecation and removal of alternatives)
* prune, prune, prune: make blocks separately downloadable, and drop 
blocks which aren't supported nor used
* make sure people don't need a bit of everything to build a decent 
Cocoon app (as in: some Actions, some Input modules, some Javascript, 
some Java, a bit of CForms, a choice over various O/R efforts, some 
Springkles here and there, and so on and so forth)

The last one doesn't mean people shouldn't use all this, it's just that 
all this is now perceived as totally separated, isolated, unrelated and 
incohesively documented stuff.

The JBoss folks were right when they told me over drinks that Cocoon is 
too much of a research project.

Just to give an example: JXTG isn't even used massively (too many folks 
still stuck with XSPs), and already we start chatting about JXTG-NG. 
How should users believe we actually care about them? (= literal remark 
I got yesterday!)

end-of-rant

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org


Mime
View raw message