Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3C78C109.504DC3B5@apache.org>
Date: Sun, 24 Feb 2002 11:31:37 +0100
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: Apache Cocoon <cocoon-dev@xml.apache.org>
Subject: Zope vs. Cocoon
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

First, kudos to Gianugo for finding the ask-slashdot thread about 'zope
vs. cocoon', one user suggested to take a look at


http://www.arielpartners.com/arielpartners/content/public/topics/technology/technologyReviews/zopeVsCocoon

which I think is a good review of the current status of the two
projects.

Yes, I've installed and used Zope in the past, even if I never created
something that worked with it.

Here I will try to address the points of the article.

                                - o - 

> The paper concludes that, despite a few annoying limitations, Zope 
> is a much more powerful, mature, and well-documented environment 
> and probably holds a one to two year lead over Cocoon and other 
> similar Java-based publishing environments. 

This quote says it all and there are a few things that I have to admit
myself:

1) well-documented: cocoon documentation is currently very poor compare
to Zope's or compared to other successful technologies (say PHP). It is
clear that without good docs, there is no good product.

But Cocoon has been released final 3 months ago and it's growth rate is
clearly impressive, even for my apache experience.

Anyway, I would venture to forecast that in a year, Cocoon will *easily*
cover this difference, also because many books are planned to appear.

2) mature: granted, you can't have a 3 months-old technology and
consider it 'mature'. At the same time, we've been working on this for
two years and we know where we're going. There is very little doubt that
Cocoon will mature and solidify soon.

3) powerful: on the technological side of things I dare to disagree with
them. Those 'few annoying limitations' they describe, I found them 'very
deep architectural mistakes'.

They cite XSLT support, but that's nothing compared to the fact that
there is no way for you to create a Zope site without the user 'knowing
it'. No matter how hard you try, it shows. It's 'zopy', they all look
the same, much like 'this is a manila-site'

Some don't think this 'cloning restriction' a severe limitation, I think
this is not a annoyance, but the *first* rule.

But this hits a very serious point: comparing Zope and Cocoon is like
comparing apples with oranges, technologically.

Boths are fruits, as both publish web content, but Zope is a 'publishing
environment' while Cocoon is a 'publishing framework'.

An 'environment' is an application that you customize, a 'framework' is
the foundation of your own application.

This is why I liked Zope as an environment, but didn't like Zope as a
framework: as an environment, all sites look similar, as a framework,
all sites might be totally different.

Just ask you this simple question: could you power cnn.com with zope
without noticing any difference? could you with Cocoon?

This tells you all.

                                  - o -

If you take a look at the table of feature comparison, you'll see that
Cocoon 'can' provide the functionality that Zope already has, but has a
module, an extension, or, as they say 'with lots of work'.

This is a good thing!

I believe that Zope is mis-placed architecturally, it's an hybrid
between a CMS and a publishing framework. And does some of everything,
but both poorly, compared to specialized solutions.

This is why I'd love to see Cocoon web applications modular: so that
people will start adding 'out-of-the-box functional modules' that zope
currently ships and people expect.

Forrest was born to provide such a module for information publishing of
OSS communities.

But you could have a 'webmail module', a wiki module, a weblog module, a
calendar module and so on.

But let's look at the features that Zope provides out of the box and
Cocoon doesn't:

1) Integrated Object-oriented database with support for full graphical
editing of all objects  

Do you really want this? I don't.

2) acquisition: Zope features dynamic run-time inheritance which enables
"context-oriented" programming. This means that objects change their
behavior based on their current context. These changes include not only
different implementations of methods, but also whole new sets of
methods. This provides many of the benefits of dynamic reclassification,
but with arguably more flexibility. Cocoon does not offer such a
feature.  

I can't really tell you what this is, so they might have a point.

3) Integrated FTP, WebDav, and HTTP access to all content

There is no way of making this possible out-of-the-box in cocoon, it's
too application specific. This is a choice. It's possible to provide
webdav support on top of cocoon today! I think I have to provide a
sample to show people how.

4) Seamless support for adding arbitrary metadata to all objects in the
database.  

XIndice will provide this. Cocoon should not have built-in databases, it
mixes concerns.

5) Integration with role-based authentication/authorization security,
all manageable from the web  

Recent code donations have removed this, even if there is lots of
cleanup work to do.

Then the Cocoon strong points:

1) Integration with Source Code Control System

Zope is not file based, it's entirely database based. So CVS doesn't
work on it.

They say this is a non-issue with file-based cocoon, but they are wrong:
revisioning is an issue with an eventual CMS on top of cocoon... but
this shows just a more balanced architecture.

2) Integration with J2EE and other Java-based business logic   

Cocoon is a servlet, thus we get it for free. They find themselves
completely detached from the rest of the world, even if they could
easily use web-services to glue things. This is a clear marketing plus
for us.

3) Support for XML and XSLT Processing pipelines  Not provided. Must
roll your own. This is a lot of work.  Cocoon does it out of the box  

What else can I say :)

No seriously: Zope is a more mature effort, but i strongly doubt that it
can stand the evolution rates that this community exhibits.

Moreover, there is no indication of internal modularity and
extensibility, SoC-based design, IoC design, data storage abstraction...
and no indication on caching strategies, scalability and performance
issues.

My impression is that they use Zope because it gives them the
functionality they need.

Cocoon is different: it will give you the 'substrate' you need to make
your functionalities grow... and give you a way to modularize these
functionalities to share add compose with others.

I think we have very little to learn from Zope that we didn't know
already.

But my point is: comparing Cocoon and Zope is an serious architectural
mistake.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


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