Chris Withers wrote:
Jim Fulton wrote:
None of this should be taken as any sort of edict. I'm also not trying to name anything. While I'd love to spur discussion, I hope not to start any arguments. :)

On that front, I'll note that I've seen 3 patterns emerge in the projects I work on:

1. Development: lots of distinct projects per machine, each using their own zope version, products and/or python libraries, and data. For me, the Zope 2 instance home model and Zope software installed in, for example, /zope/2.9.5, works perfectly

2. Production with multiple projects in an instance. Here's there are often multiple websites mapped through an Apache front end to several data sets / software sets, each in their own folder. This is the class Zope 2 model where each site uses a combination of products, zodb scripts and templates and data stored in objects within the top level folder. Again the Zope 2 instance home model works well for this, but you only tend to end up having one instance on the box, so maybe it'd be easier on sysadmins and the like if things were different in this case, although I find having everything in a sub-tree of the file system pretty compelling.

3. Large production setups with one project spread over multiple machines. Each machine has a set role, usually involving several almost-identical app servers. I think this is the case you cover well and I completely agree with the things you've said.

Have other people experienced these patterns?

If so, which do we want to support and how?

While mkzopeinstance is a fine tool, as far as it goes, it's
not flexible enough for our needs.  I'll be releasing a buildout
recipe that meets my needs. I suspect it will meet other needs as
well, but there might end up being competing recipes that handle
other needs better.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to