You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/02/24 11:31:37 UTC
Zope vs. Cocoon
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Zope-dev] Re: Zope vs. Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Oliver Bleutgen wrote:
>
> Very nice&interesting thread ...
>
> Stefano Mazzocchi wrote:
> >>"Craeg K. Strong" wrote:
> >>- Because of acquisition, you can add behavior to objects without
> >>changing their class definitions.
> >>
> >
> > Can you please elaborate more on this?
> >
> I'm sure Craeg can and will, but there's IMO a very nice explanation
> about that from Dieter Maurer, take a look at
>
> http://www.handshake.de/~dieter/pyprojects/zope/book/chap3.html#acquisition
>
> cheers,
> oliver
Uh, thanks, very nice info. I'll drink it all ASAIK.
Ciao
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Zope-dev] Re: Zope vs. Cocoon
Posted by Oliver Bleutgen <my...@gmx.net>.
Very nice&interesting thread ...
Stefano Mazzocchi wrote:
>>"Craeg K. Strong" wrote:
>>- Because of acquisition, you can add behavior to objects without
>>changing their class definitions.
>>
>
> Can you please elaborate more on this?
>
I'm sure Craeg can and will, but there's IMO a very nice explanation
about that from Dieter Maurer, take a look at
http://www.handshake.de/~dieter/pyprojects/zope/book/chap3.html#acquisition
cheers,
oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Zope vs. Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Martin Holz wrote:
>
> Stefano Mazzocchi wrote:
>
> > > http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPag
> > >e )
> >
> > Uh, cool, sounds like the new Zope3 will be much more similar to Cocoon2
> > architecturally, at least it will be component-based and
> > interface-driven.
> >
> > But given that Python doesn't have interfaces, how do you plan to have
> > polymorphism? thru reflection?
> >
>
> Any method call in python is done thru reflection.
> Calling a method in python means looking in the attribute hashmap
> of the object for a function object of that name. You can modify the values
> of the hashmap and even add or delete methods at runtime.
>
> Python interfaces, are defined thru documentation only, not a static type
> system. That's very handy for a language, which's greatest strength is rapid
> prototying.
Yes, well, might be handy for rapid prototiping, but I consider it a
limitation because I consider strong type safety a must in order create
solid architectures.
> Of course you loose compile time type checking, but that's true for
> Avalon components too.
Yes, good point.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Zope vs. Cocoon
Posted by Martin Holz <ho...@fiz-chemie.de>.
Stefano Mazzocchi wrote:
> > http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPag
> >e )
>
> Uh, cool, sounds like the new Zope3 will be much more similar to Cocoon2
> architecturally, at least it will be component-based and
> interface-driven.
>
> But given that Python doesn't have interfaces, how do you plan to have
> polymorphism? thru reflection?
>
Any method call in python is done thru reflection.
Calling a method in python means looking in the attribute hashmap
of the object for a function object of that name. You can modify the values
of the hashmap and even add or delete methods at runtime.
Python interfaces, are defined thru documentation only, not a static type
system. That's very handy for a language, which's greatest strength is rapid
prototying.
Of course you loose compile time type checking, but that's true for
Avalon components too.
--
Martin Holz <ho...@fiz-chemie.de> phone: 0049-30-39977 218
FIZ CHEMIE BERLIN
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Zope vs. Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
"Craeg K. Strong" wrote:
>
> Hello:
>
> I am the author of this paper (mea culpa! :-) and I thought I
> would respond to your comments. First off, thanks for thorough and
> thoughtful review. My responses are embedded below:
Craeg,
I have to thank you for giving us such good opportunity to learn and
improve. I must admit I'm very positively surprised to have such good
first-hand information on Zope.
See my comments intermixed below:
> >>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.
> >
> This is good news. Zope now has four (English language) books out, plus
> two more in the works. I see there is a Cocoon
> book to be published in June, but from what I understand it covers the
> Cocoon1 architecture ?
No, I can guarantee you that all books that will come out will cover
Cocoon 2.x.
> >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.
> >
> Based on experiences with Cocoon1 and the traffic on cocoon-dev, I would
> agree.
Thanks.
> >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.
> >
> I agree that this is a very important consideration. However, I cannot
> agree with your observation. Zope powers many
> more sites than those of which you may be aware. Unfortunately, I
> don't know too many of them personally, but here are a few:
>
> http://www.activestate.com
> http://www.homegain.com
> http://www.arielpartners.com (I couldn't resist :-)
Granted: I was wrong. I'm happy that I've opened my eyes on this.
> According to news at the latest Python conference
> (http://www.python10.org), Zope is now powering the websites for one
> of the major US television networks (ABC? for the life of me, I can't
> remember which). Hopefully one of the Zopistas out there
> can help me out...
No need for this, you have changed my mind and now I'll be paying *much*
more attention to Zope (and I'm sure many on this list will, as well!)
> >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.
> >
> I might define those words differently, but be that as it may.
Please, forget what I said above. It was based on an early checkout of
Zope where I was probably mislead to think it was more a CMS than a
publishing framework.
> Here is
> some information about the Zope architecture:
>
> - both Zope and Cocoon2 come with an example/tutorial that can be
> customized. Just because Zope's tutorial
> is more fully fledged does not mean that it cannot be as radically
> changed.
Ok.
> - Zope consists of an integrated object-oriented database (ZODB) and a
> webserver (ZServer, based on Medusa).
> It is possible to use ZODB with Apache in lieu of ZServer.
ok
> - Zope provides a 100% object-oriented abstraction for web publishing.
> URLs are turned into method calls on objects. The
> objects are stored in ZODB. Of course, you can create your own
> classes that obtain their content from the file system,
> rather than the ZODB (almost like a symbolic link or alias).
ok, interesting concept. Worth analysing in deeper detail.
> - Any kind of python object can be stored in ZODB. You can define your
> own objects, or use one of their predefined
> classes. Therefore, you immediately have access to all the python
> libraries, such as the XML libraries.
The need of object persistency has always been great in almost all OOP
languages... the JCP turned down the proposal to add orthogonal
persistency to Java right from the language, they thought that
serialization was good enough.
At the same time, I've always been scared away by OODBMS: the concept is
nice and clear, but I've came up with the conclusion that OODBMS for
data are somewhat useless... sure, they handle semi-structured data
better than the relational model, but providing extensibility and
polymorphism at the data level is, IMO, way too close to 'flexibility
syndrome'
But what you are painting is more a persistent layer to the underlying
logic, than a OODB for Zope data... or am I wrong? In that case, I agree
this is not a bad idea: one of the very useful Avalon blocks we designed
was an 'Object Store'
> - Because of acquisition, you can add behavior to objects without
> changing their class definitions.
Can you please elaborate more on this?
> - Because (much of) Zope content is contained in the ZODB, it is
> convenient to use ZServer because it provides access
> to objects contained in ZODB via FTP/webDAV. This makes it possible,
> for example, to edit the contents of any Zope object
> (provided you have sufficient permissions) using Emacs-FTP (see
> http://www.cs.indiana.edu/elisp/ange/ange-ftp_toc.html)
> as if it were a local file.
Yes, we have proposed a WebDAV view to the Xindice guys that will give
similar operativity.
> - The latest version of Zope (2.5.1beta1) is now using the "standalone"
> version of ZODB. Both ZServer and ZODB are
> now modular pieces that can be used separately or together, as desired.
> Doubtless, many people will continue to use them in
> their integrated form.
>
> >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?
> >
> 100% yes for both.
Cool, than it's great to compare them (and learn from each-other
mistakes)
> >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.
> >
> Actually, there is a CMS available for Zope: the Zope Content Management
> Framework (see http://cmf.zope.org).
> It is a layer on top of Zope that provides additional functionality such
> as workflow, syndication, "portlets", and reskinning.
> Apache Jetspeed provides some similar functionality to Zope CMF (though
> not all).
ok
> We chose not to use the Zope CMF because of its architecture: it is not
> based on
> standard XML technologies and, in our opinion, brings us too far into
> the "proprietary language land."
Ok
> That was an important consideration for us. In fact, I can tell you for
> certain that, if Zope were to disappear
> tomorrow (god forbid!), we could rehost our entire
> website in Cocoon2 without too much trouble because >90% of it uses
> XML/XSLT technologies. Having said that,
> we are quite happy to have all of Zope's functionality available to us.
Ok, understood.
> >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.
> >
> Perhaps I did not explain it well enough. Many of the threads on
> cocoon-dev lately have been about sitemaps and flowmaps.
> They quickly become complex. We want a simple but powerful language to
> express content objects and flows. We might
> have intermediate pieces of content created by flows that then get
> processed differently by different sub-pipelines (like the UNIX "tee").
>
> Zope provides a unique solution to this problem. Imagine a folder-like
> tree representation of your site. It consists of Manager (Folder) objects
> and ManagerItem objects. Managers are containers for ManagerItems.
> Managers are represented as folders with a familiar
> MS Windows explorer-style graphical presentation. How would you express
> pipelines?
> That is where acquisition comes in. One way to explain it is that it
> features a more recursive style, while
> Cocoon is more iterative. For example, imagine your ZODB contains the
> following:
>
> /content/index_html
> /content/topics/body
> /content/topics/swimming/intro
> /content/topics/sailing/intro
>
> In the example above, index_html is a template for a web page. It
> includes a "hole," or variable called body.
> If you call http://content/index_html directly, it will complain of an
> unresolved variable, namely "body."
>
> Similarly, /content/topics/body has an "intro" variable.
>
> Therefore, if you call the "index_html" method on the object whose URL
> (read UUID) is /content/topics/swimming, it will
> "acquire" the index_html method from /content/index_html. This is
> called acquisition by containment. The index_html
> method then acquires "body" from /content/topics/body, and finally the
> swimming intro.
>
> Recall that in Python, functions are actually first-class objects-- so
> for example you can think of /content/index_html
> as a "method" object that is contained within the /content/ folder
> object. For Java programmers, think of the GOF Strategy pattern
> on steriods :-)
>
> >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.
> >
> (see above)
>
> >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.
> >
> This gets back to the "Environment vs Framework" debate. Is an
> operating system an environment? Just because
> bourne shell is provided, does that mean I have to use it? Not if I
> have bash handy! On the other hand, on win2K, you might
> be stuck with the built-in windows commandline...
>
> Zope is more like UNIX in this regard. There are many tools provided,
> but you only use what you want to use.
> Of course, integrated FTP and webDAV access is very handy. Can you
> edit the underlying XML content of your Cocoon-powered
> site from an airport kiosk? With Zope you can, because every object
> can be edited directly using the web browser.
> Again-- this is not the normal way of doing business-- hey, we _live_ in
> Emacs. But the capability is very
> handy for those quick fixes and is a major selling point for our
> customers. An editor certainly makes life easier, but
> it is not required. This is in keeping with Python's "batteries
> included" philosophy :-)
understood
> >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.
> >
> Agreed. However, if you had a set of integration classes, tutorials,
> and documentation handy, and provided a separate
> download that combined the two products with no extra hassle required,
> how many people do you think would download it?
Careful: now it's *you* that is missing concerns. One thing is
'packaging', another think is architecture design. Sure, as a user, you
don't ultimately care how much effort it went into architecture design,
as long as the package you deployed and installed is cool for you.
You have stated that ZODB can use used separately now, so
'architecturally' the Zope people seem to agree with me that separating
concerns is a good thing.
And is also a good thing to make life easy for users, so it's good to
package things together.
I think I don't have to remind you that Cocoon itself is 18Mbs of
download and we provide out-of-the-box features like PDF generation, SVG
rasterization, XSLT transformations, SOAP services, and we also ship
with a SQL 92 capable RDBMS!
But none of these services are *core* for Cocoon!
We haven't packaged XIndice with Cocoon yet, because current version of
XIndice is CORBA based and adds another 2/3 Mbs that might not be
worth-it for now.
At the same time: we are workign closely with the XIndice community to
make sure that future versions of XIndice are Soap/XML-RPC based
(instead of CORBA, which also has several encoding interoperability
problems with most ORBs), thus much lighter and we'll probably ship that
integrated.
> >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.
> >
> We have made our first baby steps toward solving this problem:
> http://www.zope.org/Members/arielpartners/CVSFile
>
> >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.
> >
> This is the never-ending debate between Version Control Systems and
> Databases. Which do you want? Of course,
> the answer is both. It is probably only a matter of time before
> someone introduces a way to integrate CVS and Xindice,
> for example. (obviously, you could batch-export the whole bloody thing
> from Xindice and version it, but more
> granular versioning would be nice)
If you search the xindice-dev@ list you'll find some proposals of mine
for XIndice NG (whatever version that comes up to be) were versioning
should be included directly inside the database, possibly using some
advanced revisioning architecture such as Subversion's (CVS really sucks
architecturally)
> >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.
> >
> You are absolutely correct in this regard IMHO. In fact, this might be
> the biggest long term problem for Zope.
>
> - Zope is mostly written in Python, but some is (still) in C. This is
> a pain, because it makes it impossible to run
> Zope under Jython.
>
> - Python VMs are _way_ slower than Java VMs. Python just does not have
> the equivalent to the hordes of senior
> scientists working away at Sun's java labs on the "hotspot" technology.
> Obviously, both VMs will continue to improve, and
> VM performance is secondary to good architecture and design, but ...
>
> - If Zope could be made to run under Jython (http://www.jython.org),
> integration with J2EE would be virtually
> a no-brainer, b/c you are already inside a Java VM.
>
> >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.
> >
> I cannot agree with you here. Zope Corporation is the primary driving
> force behind Zope, so there are actually
> people out there who get paid to enhance Zope every day :-) I think
> their release schedule speaks for itself:
>
> 2.5.1beta1 2/22/2002
> 2.4.4beta1 1/28/2002
> 2.5.0 1/25/2002
> 2.5.0beta4 1/15/2002
> 2.5.0beta3 12/23/2001
> 2.5.0beta2 12/05/2001
> 2.5.0beta1 11/28/2001
> 2.4.3 11/12/2001
> 2.4.3beta1 11/05/2001
>
> That is just since November. In general, they have put out point
> releases every month and minor releases every six months.
> Zope 3.0 is currently under development.
Ok, cool, time will tell, then :)
> >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.
> >
> Actually, there is a RAM Cache Manager object built in to Zope. This
> object, like all other Zope objects, can
> be extended in Python (for example to change the caching strategy or
> whatnot).
>
> Zope Enterprise Objects (http://www.zope.org/Products/ZEO) is an
> optional add-on product that turns
> Zope into a distributed architecture, allowing multiple processors,
> machines, and networks to act as one website.
>
> Zope _is_ too difficult to develop for, and it is not very easy to
> create objects that can be used both inside
> and outside the Zope environment (i.e. the Zopish aspects are not
> modular enough). That is what the Zope 3.0
> effort is all about. The Zope community has learned from the Java/J2EE
> architecture: they are refactoring
> the internals of Zope so that add-ons as well as Zope itself will be
> component-based.
>
> (see:
> http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage )
Uh, cool, sounds like the new Zope3 will be much more similar to Cocoon2
architecturally, at least it will be component-based and
interface-driven.
But given that Python doesn't have interfaces, how do you plan to have
polymorphism? thru reflection?
> However, having said that, Zope _is_ amazingly extensible. Consider
> these statistics:
>
> When we first became interested in Zope (Sept/Oct 2001), there were
> about 300 add-on products available
> for Zope at the zope.org site.
>
> Today, there are over 500 add-ons available.
>
> This tells me two things: Zope has an extremely active community, Zope
> is extensible
Yes, these are admittedly great numbers.
> >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.
> >
> After reading my reply, do you still feel that way?
No, I will look more seriously into the technical details, although I
would probably be more interested from Zope3 than from Zope2. I'll post
my impressions after getting my hands dirty with more Python (which I
like, but since I couldn't write Avalon in Python, it would not be
interested in learning more of it... also, there is no very little WORA
concept in Python, which scares me to death!)
Anyway, I'll see how Zope solves the design and architectural issues we
are currently designing (expecially how it deals with flows and resource
mapping).
> >
> >
> >But my point is: comparing Cocoon and Zope is an serious architectural
> >mistake.
> >
> I agree they were created to solve different problems. However, there
> are many reasons why developers may
> want to compare the two technologies:
>
> - both are leading open-source platforms for building websites
it's cool that people start to think this way.
> - other major open source alternatives may no longer be as attractive
> (recent demise of arsdigita, enhydra's problems, ...)
yes
> - XSLT is becoming more mainstream (why Zopers might want to consider
> Cocoon)
:)
> - Inclusion of Lucene + Xindice with Cocoon narrows the gap
And I'm sure you'll see the gap narrowing a lot in the future... and
hopefully provide serious alternatives.
> In general, based on my assessment of the architectural directions of
> both projects, they are likely to
> provide more and more similar functionality as time goes on.
Oh, I'm sure about that.
> When it comes right down to it, I believe the slash-dotters were correct
> when they said that the main
> issue may be choice of programming language. If you have a development
> shop full of Java programmers,
> are you really going to expect them to learn Python and Zope?
> (Of course, that is precisely what ArielPartners did :-)
If this was so, it would be sad.
I would love to see people switching to Cocoon because they found it
better to work with and more intellectually rewarding than other
solutions.
Using the marketing power of Java and XML to bring more people to the
Cocoon front is not what I want: I want people to understand the design
choices behind cocoon and use them only if they appreciate them, not
because their boss forced them to use it.
But anyway, thanks for the good talk.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Zope-dev] Re: Zope vs. Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
seb bacon wrote:
>
> A few points I'd like to add. Before I do, a disclaimer: I've never
> used Cocoon, and I really like Zope. Having said that, I've used lots
> of other 'competing' systems, and I am able to see Zope's weak points.
>
> > >
> > >Some don't think this 'cloning restriction' a severe limitation, I think
> > >this is not a annoyance, but the *first* rule.
> > >
> > I agree that this is a very important consideration. However, I cannot
> > agree with your observation. Zope powers many
> > more sites than those of which you may be aware. Unfortunately, I
> > don't know too many of them personally, but here are a few:
> >
> > http://www.activestate.com
> > http://www.homegain.com
> > http://www.arielpartners.com (I couldn't resist :-)
>
> ...here's some more from our side of the pond:
>
> http://www.breastcancercare.org.uk
> http://www.intellident.co.uk
> http://www.mulberry-insurance.co.uk
> http://www.jubilee.gov.uk
> http://www.drugs.gov.uk
Yes, I think I got your points :)
> > >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.
>
> I disagree: Zope is very much a framework. I've used it for a CMS, for
> intranets, and for online data capture. I've created applications which
> automatically catalog and convert Word, PDF, and various image formats
> which have been emailed to a mailing list as attachments. There's bug
> trackers, wikis, slashdot-alikes, etc...
>
> What Zope lacks IMO is good best practice guidance and detailed
> developer documentation, though it's getting there now. Without best
> practice guidance, developers tend to choose the first development model
> they see, which at the moment tends towards heaps of quick-and-dirty
> through the web hacks and tricks. This does give the illusion of Zope
> being an 'environment' rather than a 'framework', and encourages
> Zopish-looking sites, too.
Ok, this probably explains my early impressions.
> > >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.
> > >
> > Actually, there is a CMS available for Zope: the Zope Content Management
> > Framework (see http://cmf.zope.org).
>
> > We chose not to use the Zope CMF because of its architecture: it is not
> > based on
> > standard XML technologies and, in our opinion, brings us too far into
> > the "proprietary language land."
>
> You don't have to be tied into one implementation if you're using the
> CMF - nothing about it is more proprietary than vanilla Zope.
>
> The default, out of the box Zope and CMF may give the impression of
> being a poor fit to most requirements. However, most people
> misunderstand that it is just an example implementation of a site built
> using the CMF. The actual possibilities are endless, and it's a robust
> and useful framework.
ok
> > >1) Integrated Object-oriented database with support for full graphical
> > >editing of all objects
> > >
> > >Do you really want this? I don't.
> > >
>
> Being able to create objects which persist transactionally in a database
> simply by mixing in a 'Persisent' class makes development very fast and
> simple. If you like programming in python, you should look into the
> ZODB a bit more - I think you'll like it, regardless of Zope.
I will take a look at all these things in great detail, believe me.
> > >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.
> > >
> > We have made our first baby steps toward solving this problem:
> > http://www.zope.org/Members/arielpartners/CVSFile
>
> This is a very real concern. There are a number of ways of dealing with
> it. We use the FSObjects from the CMF. These are filesystem-based
> objects which are loaded into the database at run-time. However, we
> still have to use DB-only things occasionally.
>
> This is all set to change in Zope3. The plan is to have full,
> bidirectional mapping between the ZODB and the filesystem.
>
> >
> > >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./listinfo/zope )
>
> > - If Zope could be made to run under Jython (http://www.jython.org),
> > integration with J2EE would be virtually
> > a no-brainer, b/c you are already inside a Java VM.
>
> This is also a goal for Zope3 (a Jython implementation), though I'm not
> sure when it'll land.
>
> > >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.
>
> You are right that there is *way* too much magick in Zope. That is the
> main motivator behind Zope3, which is entirely component-driven.
> Architecturally, it is *excellent*, and I'm very excited about it. I
> could wax on for hours, but I won't right now. Suffice to say everyone
> in the community has learned a lot from Zope2, and we're eager to build
> on that experience. See the link Craeg mentioned for more detail.
It's great to know this.
I really with you guys best luck with the new refactoring: from past
experience, I can tell you that is a long and painful process and might
create lots of forking frictions inside the community, but if done right
(and from what I read, you guys are on the right track), it could give
you *lots* of rewarding, both intellectually and from the community.
This is what Cocoon did on the transition between 1.x and 2.x and I
still have to hear a single individual that didn't like the evolution.
I'm pretty sure this will happen for Zope as well.
Take care.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Zope-dev] Re: Zope vs. Cocoon
Posted by seb bacon <se...@jamkit.com>.
A few points I'd like to add. Before I do, a disclaimer: I've never
used Cocoon, and I really like Zope. Having said that, I've used lots
of other 'competing' systems, and I am able to see Zope's weak points.
> >
> >Some don't think this 'cloning restriction' a severe limitation, I think
> >this is not a annoyance, but the *first* rule.
> >
> I agree that this is a very important consideration. However, I cannot
> agree with your observation. Zope powers many
> more sites than those of which you may be aware. Unfortunately, I
> don't know too many of them personally, but here are a few:
>
> http://www.activestate.com
> http://www.homegain.com
> http://www.arielpartners.com (I couldn't resist :-)
...here's some more from our side of the pond:
http://www.breastcancercare.org.uk
http://www.intellident.co.uk
http://www.mulberry-insurance.co.uk
http://www.jubilee.gov.uk
http://www.drugs.gov.uk
> >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.
I disagree: Zope is very much a framework. I've used it for a CMS, for
intranets, and for online data capture. I've created applications which
automatically catalog and convert Word, PDF, and various image formats
which have been emailed to a mailing list as attachments. There's bug
trackers, wikis, slashdot-alikes, etc...
What Zope lacks IMO is good best practice guidance and detailed
developer documentation, though it's getting there now. Without best
practice guidance, developers tend to choose the first development model
they see, which at the moment tends towards heaps of quick-and-dirty
through the web hacks and tricks. This does give the illusion of Zope
being an 'environment' rather than a 'framework', and encourages
Zopish-looking sites, too.
> >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.
> >
> Actually, there is a CMS available for Zope: the Zope Content Management
> Framework (see http://cmf.zope.org).
> We chose not to use the Zope CMF because of its architecture: it is not
> based on
> standard XML technologies and, in our opinion, brings us too far into
> the "proprietary language land."
You don't have to be tied into one implementation if you're using the
CMF - nothing about it is more proprietary than vanilla Zope.
The default, out of the box Zope and CMF may give the impression of
being a poor fit to most requirements. However, most people
misunderstand that it is just an example implementation of a site built
using the CMF. The actual possibilities are endless, and it's a robust
and useful framework.
> >1) Integrated Object-oriented database with support for full graphical
> >editing of all objects
> >
> >Do you really want this? I don't.
> >
Being able to create objects which persist transactionally in a database
simply by mixing in a 'Persisent' class makes development very fast and
simple. If you like programming in python, you should look into the
ZODB a bit more - I think you'll like it, regardless of Zope.
> >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.
> >
> We have made our first baby steps toward solving this problem:
> http://www.zope.org/Members/arielpartners/CVSFile
This is a very real concern. There are a number of ways of dealing with
it. We use the FSObjects from the CMF. These are filesystem-based
objects which are loaded into the database at run-time. However, we
still have to use DB-only things occasionally.
This is all set to change in Zope3. The plan is to have full,
bidirectional mapping between the ZODB and the filesystem.
>
> >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./listinfo/zope )
> - If Zope could be made to run under Jython (http://www.jython.org),
> integration with J2EE would be virtually
> a no-brainer, b/c you are already inside a Java VM.
This is also a goal for Zope3 (a Jython implementation), though I'm not
sure when it'll land.
> >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.
You are right that there is *way* too much magick in Zope. That is the
main motivator behind Zope3, which is entirely component-driven.
Architecturally, it is *excellent*, and I'm very excited about it. I
could wax on for hours, but I won't right now. Suffice to say everyone
in the community has learned a lot from Zope2, and we're eager to build
on that experience. See the link Craeg mentioned for more detail.
seb
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Carsten - Out of Action
Posted by Michael Hartle <mh...@hartle-klug.com>.
Matthew Langham wrote:
>just to let you know that Carsten will be out of action for a while. He
>played around with a chain-saw at the weekend...and injured his hand. At
>least the fingers are still _there_ :-).
>
My god, I know why I personally stick to manual-powered tools; best
wishes, hopefully he's back soon without any permanent issues.
Best regards,
Michael Hartle,
Hartle & Klug GbR
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Carsten - Out of Action
Posted by Gianugo Rabellino <gi...@apache.org>.
Matthew Langham wrote:
> just to let you know that Carsten will be out of action for a while. He
> played around with a chain-saw at the weekend...and injured his hand. At
> least the fingers are still _there_ :-).
Ouch! We should start thinking about having an insurance on valuable
programmers, like pianists and the like. :)
Carsten, I really do hope you'll get well soon. My best wishes.
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Carsten - Out of Action
Posted by Matthew Langham <ml...@s-und-n.de>.
Thanks for all your well-wishes! I have forwarded them to Carsten (not
exactly sure how he will be able to turn his home computer on to read them
though.. :-)). And I couldn't resist weblogging this "accident" :
http://www.need-a-cake.com/2002/02/25.html#a73
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Carsten - Out of Action
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 1:59 pm +0100 25/2/02, Sylvain Wallez wrote:
>Matthew Langham wrote:
>
>>Hi,
>>
>>just to let you know that Carsten will be out of action for a while. He
>>played around with a chain-saw at the weekend...and injured his hand. At
>>least the fingers are still _there_ :-).
>>
>>..he should be back in a couple of weeks.
>>
>>Matthew
>>
>Ouch, that hurts :((
>
>I experienced such a thing 10 years ago and use since then hand-powered
>tools as much as possible. Please send him all our wishes for a quick
>recovery.
I chopped the end off my left index finger 15 years ago, I was cutting
wooden wedges with a chisel (a hand tool), and had to have it sewn back on.
Beware, blunt hand tools are much more dangerous than sharp ones ;)
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Carsten - Out of Action
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Matthew Langham wrote:
>Hi,
>
>just to let you know that Carsten will be out of action for a while. He
>played around with a chain-saw at the weekend...and injured his hand. At
>least the fingers are still _there_ :-).
>
>..he should be back in a couple of weeks.
>
>Matthew
>
Ouch, that hurts :((
I experienced such a thing 10 years ago and use since then hand-powered
tools as much as possible. Please send him all our wishes for a quick
recovery.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Carsten - Out of Action
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Matthew Langham [mailto:mlangham@s-und-n.de]
>
> Hi,
>
> just to let you know that Carsten will be out of action for a while.
He
> played around with a chain-saw at the weekend...and injured his hand.
At
> least the fingers are still _there_ :-).
Brrr..
> ..he should be back in a couple of weeks.
Send him best wishes! Hope doctors will aggregate him correctly...
Vadim
>
> Matthew
>
> --
> Open Source Group sunShine - Lighting up e:Business
> =================================================================
> Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
> Weblogging at: http://www.need-a-cake.com
> =================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Carsten - Out of Action
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
First off, best wishes to Carsten. Hopefully his hand(s) are not permanently
damaged. Wish him well from cocoon-dev if you visit him, Matthew.
And now back to our regular fare.
> From: Koen Pellegrims [mailto:koen.pellegrims@pandora.be]
>
> <map:match pattern="Carsten">
> <map:aggregate>
> <map:part src="carsten/hand"/>
> <map:part src="carsten/fingers"/>
> </map:aggregate>
> <map:serialize type="human_flesh"/>
> </map:match>
Or, as Stefano (I think) put it in his mail about pipelines:
Carsten ----> Chainsaw ---> Carsten
|
|
\-------> Fingers
Do *that* in ZOPE!
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Carsten - Out of Action
Posted by Koen Pellegrims <ko...@pandora.be>.
:-)
<map:match pattern="Carsten">
<map:aggregate>
<map:part src="carsten/hand"/>
<map:part src="carsten/fingers"/>
</map:aggregate>
<map:serialize type="human_flesh"/>
</map:match>
On Mon, 25 Feb 2002, Torsten Curdt wrote:
> On Mon, 25 Feb 2002, Matthew Langham wrote:
>
> > Hi,
> >
> > just to let you know that Carsten will be out of action for a while. He
> > played around with a chain-saw at the weekend...and injured his hand. At
> > least the fingers are still _there_ :-).
> >
> > ..he should be back in a couple of weeks.
>
> Arrghh!! Best wishes....
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
Re: Carsten - Out of Action
Posted by Torsten Curdt <tc...@dff.st>.
On Mon, 25 Feb 2002, Matthew Langham wrote:
> Hi,
>
> just to let you know that Carsten will be out of action for a while. He
> played around with a chain-saw at the weekend...and injured his hand. At
> least the fingers are still _there_ :-).
>
> ..he should be back in a couple of weeks.
Arrghh!! Best wishes....
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Carsten - Out of Action
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Hi,
>
> many thanks for all your wishes - Matthew has collected them for me
> and forwarded them! My fingers are nearly alright now and I can move
> them as "before".
>
> As you can guess by this mail, I'm not "out of action" anymore and
> I'm currently trying to get through the amount of 3500 emails that
> arrived here during the last two weeks. So don't expect too much
> from me in the next hours :).
Welcome back!
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Carsten - Out of Action
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Steven Noels wrote:
>
> Carsten wrote:
>
> > I think using a mouse with a foot is much easier than using
> > the keyboard
> > as I can't bend my toes enough to select one single button at a time.
> > But perhaps with more practive it's possible.
> ^
> Yeah, right! :p
>
Argh, ok no more english emails for today... :)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Carsten - Out of Action
Posted by Steven Noels <st...@outerthought.org>.
Carsten wrote:
> I think using a mouse with a foot is much easier than using
> the keyboard
> as I can't bend my toes enough to select one single button at a time.
> But perhaps with more practive it's possible.
^
Yeah, right! :p
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Carsten - Out of Action
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> >
> >PS: No, I didn't tried to write with my feed.
> >
> Do you mean "feet" ? I've read once some "best of" stories about
> computer hot-lines : there was a man complaining using the mouse was a
> difficult thing. After much discussion, it appeared the man was using
> the mouse... with his foot ! Way difficult, especially for the wheel ;)
>
Thanks, oh my, too much german in the last weeks without any english...
yes, feet was the word I wanted to type!
I think using a mouse with a foot is much easier than using the keyboard
as I can't bend my toes enough to select one single button at a time.
But perhaps with more practive it's possible.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Carsten - Out of Action
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Hi,
>
>many thanks for all your wishes - Matthew has collected them for me
>and forwarded them! My fingers are nearly alright now and I can move
>them as "before".
>
Hi Carsten. Glad you're back :-)
>As you can guess by this mail, I'm not "out of action" anymore and
>I'm currently trying to get through the amount of 3500 emails that
>arrived here during the last two weeks. So don't expect too much
>from me in the next hours :).
>
Hehe, 3501 with this one ;)
>
>Thanks,
>
>Carsten
>
>PS: No, I didn't tried to write with my feed.
>
Do you mean "feet" ? I've read once some "best of" stories about
computer hot-lines : there was a man complaining using the mouse was a
difficult thing. After much discussion, it appeared the man was using
the mouse... with his foot ! Way difficult, especially for the wheel ;)
Cheers,
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Carsten - Out of Action
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi,
many thanks for all your wishes - Matthew has collected them for me
and forwarded them! My fingers are nearly alright now and I can move
them as "before".
As you can guess by this mail, I'm not "out of action" anymore and
I'm currently trying to get through the amount of 3500 emails that
arrived here during the last two weeks. So don't expect too much
from me in the next hours :).
Thanks,
Carsten
PS: No, I didn't tried to write with my feed.
> -----Original Message-----
> From: Matthew Langham [mailto:mlangham@s-und-n.de]
> Sent: Monday, February 25, 2002 10:10 AM
> To: cocoon-dev@xml.apache.org
> Subject: Carsten - Out of Action
>
>
> Hi,
>
> just to let you know that Carsten will be out of action for a while. He
> played around with a chain-saw at the weekend...and injured his hand. At
> least the fingers are still _there_ :-).
>
> ..he should be back in a couple of weeks.
>
> Matthew
>
> --
> Open Source Group sunShine - Lighting up e:Business
> =================================================================
> Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
> Weblogging at: http://www.need-a-cake.com
> =================================================================
>
>
>
> ---------------------------------------------------------------------
> 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
Carsten - Out of Action
Posted by Matthew Langham <ml...@s-und-n.de>.
Hi,
just to let you know that Carsten will be out of action for a while. He
played around with a chain-saw at the weekend...and injured his hand. At
least the fingers are still _there_ :-).
..he should be back in a couple of weeks.
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2 Books (was RE: Zope vs. Cocoon)
Posted by Jeremy Aston <je...@yahoo.co.uk>.
Hi Ugo,
Yes it is the same book - at least in terms of title and ISBN. I'm not sure
what happened with Sue Spielman but the book is being written from scratch
by me. As I say - it's been through the mill!
Regards
Jeremy
-----Original Message-----
From: Ugo Cei [mailto:u.cei@cbim.it]
Sent: 26 February 2002 08:41
To: cocoon-dev@xml.apache.org
Subject: Re: C2 Books (was RE: Zope vs. Cocoon)
Jeremy Aston wrote:
> Hi all,
>
> I'm pleased to be able to augment this great news with news of a book to
be
> published by Sams (www.samspublishing.com) entitled the Apache Cocoon
> Developers Handbook, ISBN 0672322579. This title has been through the
mill
> a little but is on track for publishing in a similar timeframe. I can
also
> confirm ('cos I'm bleary eyed and writing it now...) that it is definitely
> C2!
Is this the same book:
http://www.amazon.com/exec/obidos/ASIN/0672322579/104-6753684-4399137 ?
Judging from the ISBN number it should :). Is it you who's writing it or
is it Sue Spielman?
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 Books (was RE: Zope vs. Cocoon)
Posted by Ugo Cei <u....@cbim.it>.
Jeremy Aston wrote:
> Hi all,
>
> I'm pleased to be able to augment this great news with news of a book to be
> published by Sams (www.samspublishing.com) entitled the Apache Cocoon
> Developers Handbook, ISBN 0672322579. This title has been through the mill
> a little but is on track for publishing in a similar timeframe. I can also
> confirm ('cos I'm bleary eyed and writing it now...) that it is definitely
> C2!
Is this the same book:
http://www.amazon.com/exec/obidos/ASIN/0672322579/104-6753684-4399137 ?
Judging from the ISBN number it should :). Is it you who's writing it or
is it Sue Spielman?
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
C2 Books (was RE: Zope vs. Cocoon)
Posted by Jeremy Aston <je...@yahoo.co.uk>.
Hi all,
I'm pleased to be able to augment this great news with news of a book to be
published by Sams (www.samspublishing.com) entitled the Apache Cocoon
Developers Handbook, ISBN 0672322579. This title has been through the mill
a little but is on track for publishing in a similar timeframe. I can also
confirm ('cos I'm bleary eyed and writing it now...) that it is definitely
C2!
Fancy trading chapters Matthew ;-) ?
All the best
Jez
jez@pigbite.com
-----Original Message-----
From: Matthew Langham [mailto:mlangham@s-und-n.de]
Sent: 25 February 2002 07:34
To: cocoon-dev@xml.apache.org
Subject: RE: Zope vs. Cocoon
<snip:snip/>
Another book on Cocoon due out in August is this one:
http://www.newriders.com/books/title.cfm?isbn=0735712352
..and I can assure you it covers Cocoon 2 :-)
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
C2 Books (was RE: Zope vs. Cocoon)
Posted by Jeremy Aston <je...@yahoo.co.uk>.
Hi all,
I'm pleased to be able to augment this great news with news of a book to be
published by Sams (www.samspublishing.com) entitled the Apache Cocoon
Developers Handbook, ISBN 0672322579. This title has been through the mill
a little but is on track for publishing in a similar timeframe. I can also
confirm ('cos I'm bleary eyed and writing it now...) that it is definitely
C2!
Fancy trading chapters Matthew ;-) ?
All the best
Jez
jez@pigbite.com
-----Original Message-----
From: Matthew Langham [mailto:mlangham@s-und-n.de]
Sent: 25 February 2002 07:34
To: cocoon-dev@xml.apache.org
Subject: RE: Zope vs. Cocoon
<snip:snip/>
Another book on Cocoon due out in August is this one:
http://www.newriders.com/books/title.cfm?isbn=0735712352
..and I can assure you it covers Cocoon 2 :-)
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Zope vs. Cocoon
Posted by Matthew Langham <ml...@s-und-n.de>.
Hi Craeg,
>>
>
>Anyway, I would venture to forecast that in a year, Cocoon will *easily*
>cover this difference, also because many books are planned to appear.
>
This is good news. Zope now has four (English language) books out, plus
two more in the works. I see there is a Cocoon
book to be published in June, but from what I understand it covers the
Cocoon1 architecture ?
<<
Another book on Cocoon due out in August is this one:
http://www.newriders.com/books/title.cfm?isbn=0735712352
..and I can assure you it covers Cocoon 2 :-)
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Zope-dev] Re: Zope vs. Cocoon
Posted by Romain Slootmaekers <ro...@zzict.com>.
I asked the tomcat mailing list more than a year ago
what they thought about zope and got no response what so ever....
To be short: -what jsp misses is object based authorization like zope.
-what zope misses is good documentation, and something like
the catilina reactor
what we did: we moved from JSP to ZOPE February 2001 and never
looked back.
Sloot.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Zope vs. Cocoon
Posted by "Craeg K. Strong" <cs...@arielpartners.com>.
Hello:
I am the author of this paper (mea culpa! :-) and I thought I
would respond to your comments. First off, thanks for thorough and
thoughtful review. My responses are embedded below:
Stefano Mazzocchi wrote:
>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.
>
This is good news. Zope now has four (English language) books out, plus
two more in the works. I see there is a Cocoon
book to be published in June, but from what I understand it covers the
Cocoon1 architecture ?
>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.
>
Based on experiences with Cocoon1 and the traffic on cocoon-dev, I would
agree.
>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.
>
I agree that this is a very important consideration. However, I cannot
agree with your observation. Zope powers many
more sites than those of which you may be aware. Unfortunately, I
don't know too many of them personally, but here are a few:
http://www.activestate.com
http://www.homegain.com
http://www.arielpartners.com (I couldn't resist :-)
According to news at the latest Python conference
(http://www.python10.org), Zope is now powering the websites for one
of the major US television networks (ABC? for the life of me, I can't
remember which). Hopefully one of the Zopistas out there
can help me out...
>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.
>
I might define those words differently, but be that as it may. Here is
some information about the Zope architecture:
- both Zope and Cocoon2 come with an example/tutorial that can be
customized. Just because Zope's tutorial
is more fully fledged does not mean that it cannot be as radically
changed.
- Zope consists of an integrated object-oriented database (ZODB) and a
webserver (ZServer, based on Medusa).
It is possible to use ZODB with Apache in lieu of ZServer.
- Zope provides a 100% object-oriented abstraction for web publishing.
URLs are turned into method calls on objects. The
objects are stored in ZODB. Of course, you can create your own
classes that obtain their content from the file system,
rather than the ZODB (almost like a symbolic link or alias).
- Any kind of python object can be stored in ZODB. You can define your
own objects, or use one of their predefined
classes. Therefore, you immediately have access to all the python
libraries, such as the XML libraries.
- Because of acquisition, you can add behavior to objects without
changing their class definitions.
- Because (much of) Zope content is contained in the ZODB, it is
convenient to use ZServer because it provides access
to objects contained in ZODB via FTP/webDAV. This makes it possible,
for example, to edit the contents of any Zope object
(provided you have sufficient permissions) using Emacs-FTP (see
http://www.cs.indiana.edu/elisp/ange/ange-ftp_toc.html)
as if it were a local file.
- The latest version of Zope (2.5.1beta1) is now using the "standalone"
version of ZODB. Both ZServer and ZODB are
now modular pieces that can be used separately or together, as desired.
Doubtless, many people will continue to use them in
their integrated form.
>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?
>
100% yes for both.
>
>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.
>
Actually, there is a CMS available for Zope: the Zope Content Management
Framework (see http://cmf.zope.org).
It is a layer on top of Zope that provides additional functionality such
as workflow, syndication, "portlets", and reskinning.
Apache Jetspeed provides some similar functionality to Zope CMF (though
not all).
We chose not to use the Zope CMF because of its architecture: it is not
based on
standard XML technologies and, in our opinion, brings us too far into
the "proprietary language land."
That was an important consideration for us. In fact, I can tell you for
certain that, if Zope were to disappear
tomorrow (god forbid!), we could rehost our entire
website in Cocoon2 without too much trouble because >90% of it uses
XML/XSLT technologies. Having said that,
we are quite happy to have all of Zope's functionality available to us.
>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.
>
Perhaps I did not explain it well enough. Many of the threads on
cocoon-dev lately have been about sitemaps and flowmaps.
They quickly become complex. We want a simple but powerful language to
express content objects and flows. We might
have intermediate pieces of content created by flows that then get
processed differently by different sub-pipelines (like the UNIX "tee").
Zope provides a unique solution to this problem. Imagine a folder-like
tree representation of your site. It consists of Manager (Folder) objects
and ManagerItem objects. Managers are containers for ManagerItems.
Managers are represented as folders with a familiar
MS Windows explorer-style graphical presentation. How would you express
pipelines?
That is where acquisition comes in. One way to explain it is that it
features a more recursive style, while
Cocoon is more iterative. For example, imagine your ZODB contains the
following:
/content/index_html
/content/topics/body
/content/topics/swimming/intro
/content/topics/sailing/intro
In the example above, index_html is a template for a web page. It
includes a "hole," or variable called body.
If you call http://content/index_html directly, it will complain of an
unresolved variable, namely "body."
Similarly, /content/topics/body has an "intro" variable.
Therefore, if you call the "index_html" method on the object whose URL
(read UUID) is /content/topics/swimming, it will
"acquire" the index_html method from /content/index_html. This is
called acquisition by containment. The index_html
method then acquires "body" from /content/topics/body, and finally the
swimming intro.
Recall that in Python, functions are actually first-class objects-- so
for example you can think of /content/index_html
as a "method" object that is contained within the /content/ folder
object. For Java programmers, think of the GOF Strategy pattern
on steriods :-)
>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.
>
(see above)
>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.
>
This gets back to the "Environment vs Framework" debate. Is an
operating system an environment? Just because
bourne shell is provided, does that mean I have to use it? Not if I
have bash handy! On the other hand, on win2K, you might
be stuck with the built-in windows commandline...
Zope is more like UNIX in this regard. There are many tools provided,
but you only use what you want to use.
Of course, integrated FTP and webDAV access is very handy. Can you
edit the underlying XML content of your Cocoon-powered
site from an airport kiosk? With Zope you can, because every object
can be edited directly using the web browser.
Again-- this is not the normal way of doing business-- hey, we _live_ in
Emacs. But the capability is very
handy for those quick fixes and is a major selling point for our
customers. An editor certainly makes life easier, but
it is not required. This is in keeping with Python's "batteries
included" philosophy :-)
>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.
>
Agreed. However, if you had a set of integration classes, tutorials,
and documentation handy, and provided a separate
download that combined the two products with no extra hassle required,
how many people do you think would download it?
>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.
>
We have made our first baby steps toward solving this problem:
http://www.zope.org/Members/arielpartners/CVSFile
>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.
>
This is the never-ending debate between Version Control Systems and
Databases. Which do you want? Of course,
the answer is both. It is probably only a matter of time before
someone introduces a way to integrate CVS and Xindice,
for example. (obviously, you could batch-export the whole bloody thing
from Xindice and version it, but more
granular versioning would be nice)
>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.
>
You are absolutely correct in this regard IMHO. In fact, this might be
the biggest long term problem for Zope.
- Zope is mostly written in Python, but some is (still) in C. This is
a pain, because it makes it impossible to run
Zope under Jython.
- Python VMs are _way_ slower than Java VMs. Python just does not have
the equivalent to the hordes of senior
scientists working away at Sun's java labs on the "hotspot" technology.
Obviously, both VMs will continue to improve, and
VM performance is secondary to good architecture and design, but ...
- If Zope could be made to run under Jython (http://www.jython.org),
integration with J2EE would be virtually
a no-brainer, b/c you are already inside a Java VM.
>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.
>
I cannot agree with you here. Zope Corporation is the primary driving
force behind Zope, so there are actually
people out there who get paid to enhance Zope every day :-) I think
their release schedule speaks for itself:
2.5.1beta1 2/22/2002
2.4.4beta1 1/28/2002
2.5.0 1/25/2002
2.5.0beta4 1/15/2002
2.5.0beta3 12/23/2001
2.5.0beta2 12/05/2001
2.5.0beta1 11/28/2001
2.4.3 11/12/2001
2.4.3beta1 11/05/2001
That is just since November. In general, they have put out point
releases every month and minor releases every six months.
Zope 3.0 is currently under development.
>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.
>
Actually, there is a RAM Cache Manager object built in to Zope. This
object, like all other Zope objects, can
be extended in Python (for example to change the caching strategy or
whatnot).
Zope Enterprise Objects (http://www.zope.org/Products/ZEO) is an
optional add-on product that turns
Zope into a distributed architecture, allowing multiple processors,
machines, and networks to act as one website.
Zope _is_ too difficult to develop for, and it is not very easy to
create objects that can be used both inside
and outside the Zope environment (i.e. the Zopish aspects are not
modular enough). That is what the Zope 3.0
effort is all about. The Zope community has learned from the Java/J2EE
architecture: they are refactoring
the internals of Zope so that add-ons as well as Zope itself will be
component-based.
(see:
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage )
However, having said that, Zope _is_ amazingly extensible. Consider
these statistics:
When we first became interested in Zope (Sept/Oct 2001), there were
about 300 add-on products available
for Zope at the zope.org site.
Today, there are over 500 add-ons available.
This tells me two things: Zope has an extremely active community, Zope
is extensible
>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.
>
After reading my reply, do you still feel that way?
>
>
>But my point is: comparing Cocoon and Zope is an serious architectural
>mistake.
>
I agree they were created to solve different problems. However, there
are many reasons why developers may
want to compare the two technologies:
- both are leading open-source platforms for building websites
- other major open source alternatives may no longer be as attractive
(recent demise of arsdigita, enhydra's problems, ...)
- XSLT is becoming more mainstream (why Zopers might want to consider
Cocoon)
- Inclusion of Lucene + Xindice with Cocoon narrows the gap
In general, based on my assessment of the architectural directions of
both projects, they are likely to
provide more and more similar functionality as time goes on.
When it comes right down to it, I believe the slash-dotters were correct
when they said that the main
issue may be choice of programming language. If you have a development
shop full of Java programmers,
are you really going to expect them to learn Python and Zope?
(Of course, that is precisely what ArielPartners did :-)
Curious to hear your response,
--Craeg
--
Craeg K Strong, General Partner
Ariel Partners LLC
http://www.arielpartners.com
voice 781-647-2425
fax 781-647-9690
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org