On Sat, 2003-12-13 at 22:10, Stuart Bishop wrote:
Until following the steps in doc/INSTALL.txt fires up a single ZEO server bound to the loopback address and a single ZEO client (with authentication on), the vast majority of developer and production installations will be ZEO-less. This also makes ZEO-less installations the best tested and most stable environment, or at least people will assume so.
Can't argue about the assumptions, nor about how people are likely to start off using Zope; nevertheless, *every* ZC developer routinely uses ZEO, even for sandbox development. None of us would even contemplate *not* using ZEO in production: its "testedness" is pretty well established. Here are a couple of compelling reasons to run with ZEO all the time: - You can't scale Zope across hardware without ZEO, which means you need to assume that you will (or at least may) need it in production; hence, you might as well develop and test your app / site with ZEO. - ZEO lets you get a debug session open on your database without stopping the live site (this can be a lifesaver, particularly in development and site configuration; ever lock yourself out of the site by messing up the configuration of your root user folder?) - ZEO speeds restarts, often dramatically (verifying persistent caches used to be problematic, but ZODB3 3.2 has a fix for the common case). - ZEO makes ZODB-dependent unit tests run faster (another facet of the restart problem). This has been particulary true for testing products installed in INSTANCE_HOME, because the machinery for stitching together the __path__ of Products was tightly coupled to appserver startup. We might be able to fix that in future Zopes. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com