cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Orbeon vs Cocoon? - Live version available?
Date Fri, 17 Dec 2004 16:07:50 GMT
Steven Noels wrote:
> 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.

I consider myself a researcher, at times a scientists, at times I 
considered myself an artist wanna-be (but then I go to museums and 
realize how much there is to get ther), but I never ever thought I was a 
project manager. Nor I want to become one.

The day cocoon stops being what it is and starts to go after J2EE and 
.NET is the day I kiss you goodbye.

Can we have better docs? sure.

Can we prune and deprecate? you bet.

Can we make separate module available externally? yeah! Should we? most 
definately!

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

You say this as all the above lacks were a *result* of the fact that we 
are not afraid of innovate.

I'm sorry but this is just pure and ultimate bullshit.

 > 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!)

JXTG isn't used massively because we were not sure *which one* of the 
various template systems we have should become *the one* since there is 
no one that has all the benefits and none of the drawbacks.

What we are doing, Steven, is not screwing people over a silly itch to 
change where there is no need to it... we don't change interfaces around 
because their names are not polished (like avalon did, several times)... 
what we are doing is not JXTG-NG but it's an agreement on the road to a 
unified, coherent, documented and community-proposed CTemplates 
solution, that would solve all the above issues.

I don't know what you answered to that guy (nor I care, honestly) but 
blaming lack of coherence on the fact that cocoon is a research project 
is pure nonsense.

You can say that cocoon behaves differently from other projects... and 
you would be true (there will be social studies published that show 
this!) and that the rate of turn-over and innovation in cocoon is unseen 
in the majority of the projects out there (and might result in a sense 
of "moving target", this is correct).

But if any of you think that the nature of the above is *harming* rather 
than helping, I think you are not only blind but you're biting the hands 
that feeds you.

-- 
Stefano, wondering what is Steven's special talent that allows him to 
piss me off in just three paragraphs ;-)


Mime
View raw message