My apologies in advance if I causing frustration.  

> 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
> books.
I have been unable to find any significant Zope 3 documentation on
techniques for interface with SQL as was present in Zope 2.  I have had
other users respond privately with similar statements.  Your book, while
excellent, does not discuss the subject at all.  I know Zope can handle
these things, and I can setup a database adapter and create SQL scripts.
However, what is the best way to integrate these into an application?  I
could make it work, I'm sure, but I fear doing so will make cause my
application to break during a Zope upgrade or may not scale well.  I have
not been able to find any Zope 3 tutorials other than your Message Board
application. Ditto web based user management.

I installed a Zope 3 application and the Zope server would not start because
the interface specifications had changed since it was released, only 2 years
ago to point where it was broken.  They may have coded things incorrectly,
but people will do that and they will make mistakes.  

> 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
> files directly. Use overrides.zcml to make your customizations.
I disagree.  We run a variety of applications and the most complex
configuration files we have are in Apache, Nagios, and Exim; which
surprisingly are the least complex applications we run.  All of them offer
configuration file testers, which are extremely good about pinpointing
specific errors.  Not to mention that all are relatively widely used and
docs are easy to find.  The Zope 2 configuration for example is not as
difficult.  Java based applications are the only ones I know that have
complex configurations.  Our company deploys very complex financial based
transactions systems we have only a handful of about 10 very small config
files which just contain database connection strings. 

We installed your Message Board application for example (step13), and the
server would not start. I was unclear why (I think it had to do with the
smileys).  I probably could have figured it out, but there were some
configuration files that required change, such as adding a file to
../etc/package-includes - but I'm a pretty experienced user and engineer.
It does require some configuration.  

> 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
> administration.
> 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
> this.
People are just plain stupid.  Unfortunately it's a reality.  We have high
end clients we have to pamper (you work for one we're trying to get to at
the moment), and we have to accept blame for their breakages if we want them
to keep paying us.  ZCML files look like configuration files and so they get
played with when people get frustrated confused or just want to check on

We just installed the MySQL adapater, and it requires adjustments to
etc/package-includes.  If I asked my system admin to install the Message
Board application, step13, he would get an error because the smileys are
missing.  I can almost guarantee he would play with the ".zcml" files as a
natural first step to diagnose the problem.  He is very bright.

For example, just the other day we had a system administrator edit a
configuration file, and through some VI keystrokes during exiting, he
managed to replace the first half of the file with an asterisk, and he
didn't notice.  The application continued to run, and restart without
problems(BTW) despite missing half it's config.  We only picked it up
through a monitoring tool we have and security tools we have.

In a moment of crisis, one wants an application that has a high tolerance
for errors and problems.  In regards to system crashes, lots of strange
things can happen, and files can get corrupted.  It is not as simple as
re-installing or restoring from backup, if you think all the files are
intact.  A corruption error can cause a subtle yet important change in
another wise apparently normal looking file.  Or some error someplace else
could manifest itself in Zope.  In these situations, you want to have
applications that report to you where there are errors and where to focus on
fixing them.  The files can be restored or repaired as necessary.  Currently
an error in Zope produces a long laundry list of files, and errors that are
vague and "line" numbers that appear to be fractions (such as 11.7-11.41).  

I would vote for zero config files if it were a choice.        

> 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
> of
> - 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.
It is helpful to know these are out there.  Thanks.  Do you know of any
mission critical Zope 3 applications yet? eBay, Amazon, grade? We plan on
producing a virtual bank with distributed transaction processing around the
globe and variety of interfaces to third party financial processors and
legacy systems.  I think we're going to go forward with Zope 3, but I am
> 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.
I agree, and maybe this is the result of this project being relatively new.
Hopefully I might be able to assist.  
> > 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?
I followed the documentation straight out of your book on this one, using
IE. I have general trouble adding and editing messages.  I do not know about
GNU gettext. 
1. Add translation domain
2. Click on Translate view
3. Try to add messages
(Messages do not get added)

> > Errors in general seem to give unexplainable results.
> Could you give examples?
I just installed the MySQL adapter, and I try to create a connection, and I
make an error (bad username or something). Instead of an error, I receive
"The page cannot be displayed"; I need to hit back to get back to ZMI.  It
works, but it's a bit odd.  I can check the error log to find out why.  It
just makes think that things are not well thought out or that application
development is rushed.

> 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.
I agree, and *HOPE* to do so.  

Thanks again for your kind and polite dialogue.  

Zope3-users mailing list

Reply via email to