Short part:

Use ZEO. ZEO rocks. Really. In essence it’s just the ZODB with a small communication layer on top. This layer is used in Zope instances instead of using the ZODB directly. That way you can run several process groups on your machine, all connecting to the same database. This helps with the above mentioned process restarting: when one is down, the other does the work. Use mod_backhand in Apache to distribute the load between the process groups or use other load balancing tools. ZEO makes regular database packs easier, too: they run on the server and not in the Zope instances - they actually don’t notice much of the running pack. If you have, use a SMP machine. Or buy one. Really - that helps. You need to run ZEO and multiple Zope instances, though - otherwise the global interpreter lock of Python will hit you over the head and Zope will just use one of the two processors. That’s one reason why you want multiple process groups in the first place - distribution of load on the machine itself, making use of multiple processors.

It publishes a tree of objects stored in the ZODB which is an object oriented database. Think of it as a monstrous pickle implementation.

Zope folders are a lot like user-defined classes in your application. They contain things, which is why they're called "folders". But basically, from a programming perspective, what they contain are their "attributes" in the class/object jargon (in reality it can be more complicated, some containers use Python container types like dictionary or list as their internal structure).

Of course, "publishes" means "publishes to the web".

Z:

So Zope includes an object store, a publisher, and a web server. When the web server receives a request, it asks the publisher to get it, which digs it out of the object store. Then it goes back the other way, back to the requester via the web.

Usually, you run the Zope webserver behind another proxy like Apache, but it is possible to serve a site directly from Zope. I never do that for production, because, Apache, being much more completely tested is a safer bet for not crashing or misbehaving under heavy loads. However, the built-in Zope webserver (I believe it was once called Medusa) is quite convenient for development and testing.

OBJECT:

Because Zope publishes Python objects instead of files, they can have much richer structure (e.g. metadata) than a site based on files stored in a filesystem. However, a set of files stored in a filesystem is very much like an object database, so

1) The ZODB is sometimes called the Zope Object FileSystem, which I find a useful idea --- especially since ZOFS has some extra constraints beyond what ZODB requires.

2) You actually can store contents of the ZODB as a filesystem with associated metadata in auxiliary files. I believe this is how the "filesystem storage" option for ZODB works (by default, ZODB lumps all its data into one big container file "Data.fs" -- this is the "filestorage" option).

PUBLISHING:

Zope has also been called a "web application server", because it's relatively easy to write highly-integrated, highly-dynamic sites with it (and overkill to use it for purely static sites).

Objects are defined in such a way that they can be represented as web pages. The publisher has a lot of default behaviors for built-in types and the objects that come with Zope.

Zope "product" developers have the responsibility (and control) over how their objects will appear when published.

ENVIRONMENT:

If you want to think of it as a "web application server", then basically, Zope is your "operating system", and your site is your "web application software".

Zope also provides some specialized programming language help --- Python scripts that can be edited through the web, and two "Templating Languages" for designing web pages that will have dynamic content. You can think of the templating languages as being similar to PHP or ASP style programming.

But "Zope Zen" says that the serious code should be either in Python scripts or in Python products (on the filesystem, instead of in the ZODB, like scripts). Templates are meant to be simple, simple, simple. But that's a style issue.

This stuff provides the Zope "operating system" with a "shell". And the "Zope Management Interface", which is what you see when you visit the /manage page at a Zope site, is the "window system" or, perhaps more accurately, the "file browser" of that "operating system".

So, in fact, Zope does quite a bit. But it isn't really all that hard to understand. It's just not been well-introduced, because the people explaining it have a tendency to forget that it isn't all obvious, because it seems that way to them, now that they know it.

Restart zope and add a plone site with the id plone1. Note: You must create the folder after adding the moint point.

When using seperate dbs it's very easy to migrate some instances to a second server. You don't need to export a large site but simply copy the files and the sections in the zope.conf