Even though I think it is pointless, I am going to reply to some of the points 
you make.

On Saturday 14 January 2006 11:51, David Johnson 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.

I have absolutely no idea what you are talking about. A lot of the packages in 
Zope 3 have text documentation files that define the API very well. 
Furthermore, the interfaces document the API on a programming level. Tools 
like API doc pull a lot of this information (and much more) together. Other 
than that, there are many beginner tutorials out there now and we have 2 

We commit to an API for 2 releases after it is deprecated. If you find that a 
new release breaks your code, then you can consider it a bug and report it.

> Configuration is done through a series of configuration 
> files, which are easily broken and difficult to traverse.  If the
> configuration is damaged in someway through a mistake or other reason, the
> server will not restart until it is fixed, which presents serious
> challenges in a production environment - in the heat of the moment, wading
> through errors is not trivial, especially for the non-Zope experienced
> system admin who will be on call at 2:00 AM.  The errors are difficult to
> comprehend and do not easily point out where problems lie.  Once problems
> are found it is difficult to understand what they mean.

First of all, if you break any configuration file, not just Zope's, an 
application will not start. Note that someone should never mess with the ZCML 
files directly. Use overrides.zcml to make your customizations.

As to the production system, if you change configuration on a life production 
system, you are plain stupid. Also, the system administrator should *never* 
mess with ZCML. ZCML is application developer domain, not system 

Also, I don't understand why a crashed server would cause anyone to mess with 
ZCML on a production system. I sincerely have no clue how you came up with 

> I can only find one semi real-world Zope 3 example (the SIP application),
> and it does not even run under Zope 3.2;

Aehm, not every application Zope 3 is used in is a public project. Here are 
other applications that have been deployed:

- Zope Corp. Document Management System (closed)
- Tiks, a CMS for Zope 3 [a fairly large Web site has been in production using 
Tiks] (open)
- Another large document management application, which I do not know the name 
- Launchpad and other Ubuntu-related software
- SchoolTool/SchoolBell; I know that SchoolBell is used in several schools and 
universities around the world.

These are some of the pure Zope 3 projects I know about; there are surely many 
that use Five.

> while I've been able to wade 
> through and fix many errors, I continue to get more as the interfaces and
> standards keep changing.

If people do not report API breakage, then we cannot fix it. I tried very hard 
to provide good backward-compatibility, but it's not an easy task and 
problems are expected.

> Even the current i18n facility does not seem to 
> work properly, editing messages frequently gives errors and does not update
> properly.

SchoolTool uses the i18n facilities heavily and we have never had update 
problems. Are you sure you know how GNU gettext works properly?

> Errors in general seem to give unexplainable results. 

Could you give examples?

> 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.

You have to be much more specific to provide constructive feedback. If you are 
unhappy with some part of the architecture, make a proposal or at least bring 
it up on zope3-dev.

> Has anyone produced a significant application in Zope 3?

Yes, see above. I am personally involved in SchoolTool and it is pretty big 
and stable. We have had no problems that are due to Zope 3 issues.

> Has it been relatively bug-free?

Yes. We do not get too many bug reports. Most of them are not even very 
serious. Note that Zope 3 is one of the first (if not the first) Open Source 
projects that uses test-driven development. All tests always have to pass 
before a check-in can be made.

> Has it integrated with an RDBMS? 

Zope natively uses the ZODB, which most Zope 3 application developers prefer 
to use. It also depends what you mean by integration. Zope 3 supports 
connecting to RDBs using utilities and making queries that are integrated in 
the transaction mechanism. If you want higher-level integration, there is 
sqlos. Nuxeo is working on an even higher level API to interface RDBs with 
Zope 3.

Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-users mailing list

Reply via email to