Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Reply-To: <lmorandini@ieee.org>
From: "Luca Morandini" <luca.morandini1@tin.it>
To: <cocoon-dev@xml.apache.org>
Subject: Cocoon in the corporate world [WAS: RE: [CLEANCOON] Let's clean
 Cocoon and modularize it]
Date: Tue, 6 Aug 2002 11:59:55 +0200
Message-ID: <LGEDIKJICGOANGDLBIJDCEAJCNAA.luca.morandini1@tin.it>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3D4F977D.8080806@denic.de>

Ulrich,

I appreciate your well-thought comments, but I have a couple counter-points of my own:

1) If Sun came out with an XML equivalent to JSP, this wouldn't necessary mean the demise of Cocoon: just think of Apache HTTP
server, it survived iPlanet and IIS nicely

2) I sold three Cocoon projects so far, and the IT people was rather interested in it (whether they will build on this interest
remains to be seen though).

However, I must reckon that Cocoon is "unstable", and this worries me quite a bit, especially with Cocoon books coming out of the
press.

Best regards,

---------------------------------------------
               Luca Morandini
               GIS Consultant
              lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------


> -----Original Message-----
> From: Ulrich Mayring [mailto:ulim@denic.de]
> Sent: Tuesday, August 06, 2002 11:32 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [CLEANCOON] Let's clean Cocoon and modularize it
>
>
> 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
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org