[Zope] Zope Stability Question

[Greg Ward]

On 09 March 2000, James W. Howe said:
> >The perfect counter argument is.  "Prove it."  If this person asks *you*
> >to prove it, show them the Lawrence Livermore National Labs, the
> >mems-exchange (all multi-million $+ scientific establishments), Jon
> >Udell articles, etc etc.  There is a mountain of evidence on your side
> >and nothing on his/hers.
> 
> Do you have specific URL's you could point me at for these items.

My main achievement with Zope is part of the MEMS Exchange mentioned by
Michel:

   http://www.mems-exchange.org/z/process/builder/

This is a tool for people to specify the process sequence to fabricate a
MEMS device (= micro-electro-mechanical system, aka micromachine or
microsystem).  They're typically fabricated using the same techniques as
IC fab, but in much more varied ways -- hence the need for people to
specify custom fabrication sequences.  For non-specialists, most of this
tool is meaningless, but it's an interesting demo of how much user
interface you can get away with on the web using something like Zope.

For the record, before we started playing with Zope, I was convinced
that complex user interfaces on the web were all-but-impossible.  Thanks
to Zope, I now believe that complex user interfaces on the web are
merely very difficult.  

We have found no bugs in Python developing this system; we certainly
have our share of gripes with Zope, but I think we've only seen two bugs
that really affected the reliability of our web site.  The first bug was
when Zope 2.1 came out, and we made the mistake of going straight from a
single-threaded, PCGI, Zope 2.0 installation to multi-threaded, FastCGI,
Zope 2.1; things got really flaky.  I think we're now running
single-threaded, PCGI, Zope 2.1.4 and things are peachy.  We really need
to step gingerly back into multi-threaded/FastCGI territory to see how
it behaves.  The other bug was a nasty ref-counting problem deep in the
bowels of mxODBC, so can't really be blamed on Zope.

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913