[Zope3-Users] Zope 3 Ready for Production? Really?

[Jeff Shell]

I know that Stephan Richter has responded to many of these points.
I'll add in some of my views as someone from the borderlands - I'm not
a core developer, but I am someone who has used Zope since before it
was Zope. Since before it was "before it was Zope". I worked on core
Principia and Zope a long time ago, but have not been involved much
with the core of Zope 3 besides following the conversations and
chiming in (sometimes too much, sometimes asking unanswerable
questions) on the mailing lists.

After tinkering with Zope 3 for a while, late last summer I had to
build a Zope 3 application for real, and do it real fast.

On 1/14/06, David Johnson <djohnson at jsatech.com> wrote:
>
> The documentation is not well defined, which makes deployment dangerous
> because one may produce an application that does not conform to future
> releases of Zope.

Documentation is better defined than any previous release of Zope.
Most of the documentation, as Stephen mentions, is at the API level
and is used as doctests. I installed Zope 3.2 final on our development
boxes the other day. Over 8000 tests ran succesfully, many of those
coming from documentation. It's not only documentation, but
documentation that works.

Interfaces are generally well defined and in apidoc. There are some
that don't make it into apidoc, and that can be frustrating. I need to
make a better list of the ones I look for that I can't find so I can
submit it as a collector issue. But generally, it is all very well
defined. ZCML is well documented, which was a huge concern I had
during Zope 3's development process.

There are two published books. They are old, covering Zope 3.0, but I
know www.worldcookery.com has updates for its book. Even though the
books are a couple of releases old, many of the core concepts still
apply. I'm trying to get back in the habit of consulting Stephan's
book before asking a question of the mailing list.

On the downside, there isn't much documentation showing how to pull a
lot of this together. But how you pull it together is up to you. A
twenty minute wiki how-to isn't going to provide you with good tips
about how to write an e-commerce solution. An e-commerce how-to isn't
going to help you write a knowledge base. There could be more
documentation in this area, but writing it is hard when you've got
full time jobs doing other things. Keeping it updated is even harder.
This is affecting TurboGears, Django, and more - they have some good
"get started quick!" tutorials. They've had issues keeping them up to
date recently.

The Wiki is terrible. But I hate wikis and if I believed in God I
believe my god would consider Wikis an abomination unto him. It's good
that there's a place for information to go that's reasonably central.
But which of the various "related objects" proposals is current? So I
never go in there. I get frustrated very quickly, and this is with a
lot of work done by others to try to keep it organized.

I like Trac, or even the Plone (I assume) based tools Schoolbell is
using to publish information. "This is the 3.2 milestone. Here are the
proposals and issues that are tied to that milestone" You can do this
with Wikis, but it's all manual and the organization is seldom as nice
and natural. Compare these (and yes, I'm aware that trac has a wiki -
but it seems nice and secondary to some of the core information):

http://trac.turbogears.org/turbogears/roadmap
http://dev.zope.org/Zope3/RoadMap

But while that would be nice, I don't have the time or experience to
contribute to setting something like that up even if it were wanted by
others, and I'm not volunteering anyone else to do it. Just wishful
thinking. It's hard for me to find a decision tree of what went into
Zope 3.2 and why, or to try to lobby support for something to go in
Zope 3.3 and see proof somehow that it does by being able to follow an
issue, a roadmap, a plan, etc.

(The bug tracker product Stephan wrote in Zope 3 was really cool with
grouping. I miss it).

Regarding configuration, Stephan provided nice responses.

> I can only find one semi real-world Zope 3 example (the SIP application),
> and it does not even run under Zope 3.2; while I've been able to wade
> through and fix many errors, I continue to get more as the interfaces and
> standards keep changing. Even the current i18n facility does not seem to
> work properly, editing messages frequently gives errors and does not update
> properly.  Errors in general seem to give unexplainable results.

I struggle with i18n, but I admit to being a stupid American that
wishes he didn't have to deal with it at all. This has nothing to do
with Zope 3's implementation - it's just not a habit that I have.
Getting used to unicode, encodings, messages, etc, was hard. But again
- a admit complete and utter ignorance here.

On the other hand - the question that I saw listed most on the "submit
a question" list for the Snakes and Rubies meeting in Chicago had to
deal with "when are you going to internationalize Rails?" It made me
smile, knowing that Zope 3 dealt with that early and deep.

It is annoying to see the MessageIDFactory deprecation warnings. I
only have those and use those because I copied and pasted from
something else and ran with it. For people like me, someone needs to
write a "Basic Zope 3 Internationalization For Ignorant Americans". My
customers don't need it, but if I don't provide it in some places,
Zope 3 yells at me and then I feel sad... So knowing when you need
them, when you need the i18n_domain in ZCML, would be nice. But this
has never stopped me from charging ahead with Zope 3.

> I do see many advantages to Zope 3 and I am willing to tolerate a lot
> because of those advantages, but it seems like it not quite polished yet,
> and there may be some architectural issues that are problematic for
> real-world use.

It's not an architecture that's suited to everything under the sun.
But it's certainly in real world use.

> Has anyone produced a significant application in Zope 3? Has it been
> relatively bug-free?  Has it integrated with an RDBMS?

Yes. As I may have mentioned before, we converted our biggest customer
over to Zope 3 this summer. We did it in a matter of weeks. It was a
complete rewrite - their prior site was written using many different
Zope 2 styles and techniques that we've used over the years to try to
solve different problems.

Big sites, big traffic. Custom FTP uploading and file management, a
decent web based admin interface that eclipses anything we've done as
a company prior to this. Integrated with an RDBMS for some data, but
most of the content coming out of the ZODB.

More than relatively bug free, and most bugs were easy to patch. This
customer cannot have downtime, especially at this time of year.

We then used some of what we did for them and applied it to three of
that customer's sister companies. The last site we turned around in a
week, including graphic design and all custom development.

After that, we've made some major refactorings and restructurings to
the underlying stack (our own set of packages that build on Zope 3).

Zope 3.2 fixed a bug in Zope 3.1. The 3.1 bug didn't affect us, but
the fix did. But this was our problem, not Zope's. It exposes some
design flaws in our code that came from the rushed learning and
devlopment of the core. Fixing those, testing them across four sites,
and making sure the fixes worked in both Zope 3.1 and 3.2 took about a
week - and a lot of that week was spent writing our own policies. "If
you want a container, use this class. If  it's like a folder and you
want the folder responsibilities, use this interface..." (those
classes and interfaces being our own core ones, and ones that were
confusing before - again due to our own rushed development and not
having anything to do with Zope per se). That week also involved just
really digging out some common code that had been copied across
customers and moved into the core. And then the branch was merged back
in to the trunk and all four customers were updated. I think there was
only one minor hiccup, and it was fixed in three lines. I cannot
convey to you the magnitude of this project - it was a major
refactoring, paying back technical debt accrued during rapid
development and earlier deadlines. Most projects have to do this in
their lifetime. But applying the updates to the public servers?
Painless. I call that bug free.