cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <>
Subject Re: [CLEANCOON] Let's clean Cocoon and modularize it
Date Tue, 06 Aug 2002 09:31:41 GMT
Stuart Roebuck wrote:

 > Okay, I wonder if it's time for me to poor water on the flames!

Well, every couple of months I come back here to check the current 
status of Cocoon and comment on it. This is more like pouring oil on the 
flames, but maybe an outsider's perspective can be useful at times.

 > * Cocoon 2.0.3 has some problems with it that need fixing.
 > * Cocoon 2.1 hasn't been released yet.

It used to be the same situation with Cocoon 1.x. There were some 
problems with it, but fixing them was deemed to be too much of a change 
to the existing codebase. So it was delayed to Cocoon2, which is a whole 
new architecture.

 > * There's a whole bundle of software running 'out there' based on
 > Cocoon 1.x and 2.0.x that relies on any number of the existing
 > 'unstable' APIs in Cocoon.

Absolutely. We have a very big investment in our Cocoon1-based apps and 
currently don't know what to do. We are wary to migrate to Cocoon2 for 
several reasons:

- Our Cocoon1-based apps work and are mission-critical. The only problem 
is performance, but we can always throw hardware at it.
- Cocoon2 is too complex. It needs a commitment that is larger by a 
factor of 3 or 4. Corporate users won't make that large a commitment to 
something that is not stable and not an industry standard.
- To our usage patterns Cocoon2 does not offer any advantage over 
Cocoon1 except performance, while being much harder to use and needing 
much more maintenance.
- We simply have other things to do. Cocoon is not the center of our 
world (even though I personally would like that).

So, we're kind of waiting for "something to happen". Experience teaches 
that one of these days someone will come out with something. I think Sun 
will one day come up with an XML equivalent to JSP and that, sad as it 
may be, could be the end of Cocoon. In the meantime our Cocoon1-based 
apps work, Cocoon1 appears to be bug-free and stable.

 > And now we're talking about refactoring everything.

Or even rewriting everything.

 > Cocoon may be the best thing since sliced bread, but nobody's going to
 > put their fingers anywhere near it whilst it's still being sliced.

Have you ever wondered why PHP and similar technologies are so 
successful in the market? They are easy to install (mostly come 
pre-installed with Apache anyway), easy to configure, easy to use. They 
are fast, stable and secure enough for webhosting. Nowadays almost every 
serious webhoster offers something like PHP or Perl - but who offers 
Cocoon? Sure, the industry sees the value of XML-based processing, but 
they don't adopt Cocoon, they are either building their own thing 
(Roxen) or extending their existing technology (Perl).

Nowadays it's hard to find a content management system that does not 
loudly proclaim to support XML. It won't be long before almost every CMS 
will be able to do XML-based processing and to publish dynamically on 
the Web. None of the CMSes that I know use Cocoon for that, instead 
they're all developing their own thing.

So, at one point in the future Cocoon will lose its advantage that it 
has no competition. And if it loses that, it won't be the best thing 
since sliced bread anymore. I've tried to win people over to the Cocoon1 
platform, when it still was current. Many of them, however, said that it 
was too hard to use. They'd rather wait for their existing technology to 
support XML. When I told them that their existing technology will only 
ever support XML as an afterthought, while Cocoon1 is built from the 
ground up to work with XML, they said: "that's as maybe, it may not be 
elegant, but we can leverage our existing knowledge and the less time we 
need to port our apps over, the greater the return on investment."

Ok, that's corporate thinking, it may not be applicable to a project 
such as this. Just my two cents, please no-one take it personally, ok? :)


Ulrich Mayring
DENIC eG, Systementwicklung

To unsubscribe, e-mail:
For additional commands, email:

View raw message