Zope as a Particularly Frustrating Section of Adventure

All direct links to Zope.org have been removed, in the hope that others will not fall prey to this evil.

4am, Tuesday, May 16, 2000:

This is a silly document I wrote one night after yet another frustrating day dealing with badly written open source programs. The primary metaphor to hold (firmly) in your mind is that of Adventure: remember? "You are in a maze of twisty little passages, all alike."

I was moved to write this directly by considerations of Zope that flitted through my mind as I was trying to integrate Zope with PyWX. In particular, what recurringly traveled at high velocities through my gray matter was the thought, "This sucks."

You can either share my pain by following the path outlined below, which started with me trying to find some documentation on how things actually worked and ended in me weeping, or you can just skip right to the bottom.

Note that I had already decided the Zope was evil long before looking into this. Now I was merely trying to figure out how it worked well enough to connect to it from a program that the Zope developers didn't write. long story short: this is impossible, no matter how many chickens you sacrifice.

The journey begins...

One must know one's enemy. I will study Zope, so that I can learn from the mistakes of others.

The documentation odyssey: still at the entrance to the beast's cave

I, no dilettante adventurer, tackle the project head on. I mouse over to www.zope.org/Documentation/, and view the tantalizing links that await me. But wait! What do I see here? 'tis a Guides link, that promises to be "...the first stop in learning about Zope".

Shall I enter? This promises to be the well-lit entrance - but I know from my previous experiences that it's probably too good to be true. Going against my better judgement, risking frustration, I click on it.

Still at the entrance!

I moved, but I did not move! Everything is the same, but different! The font has changed, but the content has not -- ahh, but no, a doorway to another realm has vanished -- the Zope Documentation Project is no longer accessible!

This is an odd occurrence -- normally, a doorway leads somewhere new -- but I am willing to test the limits of this fetishistic system.

The Zope Administrators Guide looks interesting -- surely it will be technical!

The Zope Administrators Guide is no help.

(but it's got a Z sound, so it's still cool...)

What's this? It's not visible! I see a box - tightly compressed. Nothing else.

I open it.

It's ZAP! No, ZAG! No...

(but it's got a Z sound -- and it's ZPLed!! -- so it's still cool...)

I ponder the wisdom of the ancients:

1. First, I shall create a Web server;
2. Then, I shall document it (albeit incompletely) in HTML;
3. Finally, I shall distribute it in a format that cannot be read through my Web site.

Nope, still doesn't make sense.

Gamely, I read on.

Persist... no, it's FASTCGI

I study the persistent/fast CGI documentation. It mystifies me -- what is the difference? Ahh -- one is written by Digicool.

But that is irrelevant -- I move on to the critical section, which discusses how to run Zope from a different Web server.

Documentation is incomplete. Please come back later.

I am yet again confounded -- no docs!

Feel the source, Luke!

Not even mixed metaphors will stop me!

I decide to drill deep into the construction of this bizarre maze; perhaps going through the walls will be faster?

Bewildered in PCGI-land.

I once again confront Persistent CGI. Alas, it is impenetrable -- the source code is in C! Hmm. Looks obfuscated. Oh, I see -- it's socket programming!

Once again, I ponder the wisdom of the ancients -- developing a Web/Application server in Python, which is ideal for socket programming, while coding the PersistentCGI client in C seems... strange -- and once again I am mystified.

Back to the docs.

Obviously, I need to read more.

Yet, after consideration of knowledge gained vs. time spent gaining it, I give up. Clearly an infinite amount of time would be needed.

Sob.

Summary Observations from my Zope Experience:

1. Zope violates a cardinal rule of open source projects.

Thus, Zope sucks, either because it's badly designed or its documentation is badly written.

2. ZODB is not (yet) a real database.

Thus, Zope sucks, because I have to figure out how everything works before I can use it to do advanced stuff.

OK, I'll admit it -- I'm impressed with ZODB. It looks well thought through, from the class hierarchy. So why on earth haven't they divorced it a bit more from Zope and made it usable to the hungry masses crying out for an OODBMS??

3. Zope Documentation is, in general, not readable on line.

Thus, Zope sucks, because clearly the authors have not thought about how people are actually going to use their site.

4. Zope cannot be easily divorced from Medusa.

Thus, Zope sucks, because they are producing a badly documented monolothic software architecture that has one entry point for sytems administrators.

Short Summary

1. Zope is evil.

   Zope is evil because it is a beta-level software project masquerading as a complete development environment, and, as this is not admitted in open air, newbies are sucked in expecting something easy to use and expand.

2. Zope is even more evil because it promises much, and may deliver it, but who the hell can tell? Certainly not someone who wants to spend less than 20 hours evaluating the package. By then, I at least would have written my 2000 lines of Tcl code (for AOLserver/ACS) and gone to sleep.

3. Zope is yet even more evil because it doesn't incrementally reward the user for progress. AOLserver is great for the attention-span challenged -- hey, look, my Tcl file is saying Hello, World! And look, I just accessed a database! Apache is even better for the attention-span challenged -- look, ma, an Apache stub Web site! after 15 seconds and no hands! Both Apache and AOLserver will reward effort with proportional results, but they will do so without a lower threshold.

4. And, finally, Zope is beyond evil because they're coopting all the good Z names.

Good night, and I hope you enjoyed this... Evening with Titus.

P.S. Enter the Zdragon... you've been warned!

1:30pm, the morning after.

I just found this on Byte: Zope is Python's Killer App. Whimper.

Counter: there are some cute opinions on Zope in the pywx advocacy area.

1:30pm, May 23rd, 2000.

This piece has now come in handy!! Zome poor fella wrote an article on why Zope is "better" than the ACS -- check out http://www.zope.org/Members/tazzzzz/ACSandZope. Personally, I figure he chose Zope so that he could use the name 'tazzzzz' without people asking him about it.

Let's see how long this server stands up to the (inevitable) denial-of-service attack... Ah, well, the only things that'll crash are Apache and Zope, not AOLserver!

For you Zopes who have been referred here by some inflammatory posting on the Zope-Dev mailing list, you can check out a couple of reasoned responses on the OpenACS bboard.

(Note that I don't have a community college degree in C++ -- that must be why I don't understand Zope, despite the complete lack of intelligible documentation. Sigh.)

Also, you should check out PyWX so that our advertisers will get more page counts.

July 17th, 2001.

Due to popular demand (about 4 people asked) I resurrected this page and moved it to a new server. I couldn't keep Zope running on the old one, and I didn't want to have to keep up with the bug fixes for Yet Another Web Service, so it's now running under Apache.

A number of things have happened in the Zope/Python world since then. In no particular order:

• The Python Team (GvR et al.) have been absorbed by Digital Creations.

  It is not yet clear if this is a Bad Thing.

• I presented a paper on PyWX at Python 9, and met a lot of friendly, nice, and somewhat smug Zope people.

• Webware was mentioned loudly at the Python 9 concluding talk.

• Zope has advanced to have many nifty features (like WebDAV support) that make me drool.

• Andrew Kuchling has made a standalone version of ZODB available. I still couldn't get it to work, but I must say that I trust AMK more than most other Python folks, so I'm sure it'll get there someday.

• Andrew Kuchling also put up a Web age on why he didn't use Zope. He characterizes the PyWX advocacy page as "overly harsh"; I wonder what he'd say about this page ;).