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
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 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list