Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote at 2007-1-3 17:12 -0500: > >There will be an instance recipe that can generate instances that use >applications. In a (Unix) production deployment, these instances >will have their files spread around more or less according to http:// >www.pathname.com/fhs/. There won't be an instance directory. For >development, instances will probably still be directories, but will >be much smaller and shallower than those produced by the existing >mkzopeinstance. They will probably have a zope.conf files and >control scripts and their directories will also contain log and >zdaemon socket files. Configuration files, too, share many common parts across instances. Of course, you may say that these parts belong in fact to the application and not the instances. However, I am unsure whether e.g. the size of (general) caches or the available servers (HTTP, FTP, ...) should be considered application specific. We avoid this duplication in "ZConfig" configuration files by two "ZConfig" extensions (submitted to the collector a long time ago): a "%redefine" directive (to override common defaults by instance specific definitions) and a "$(function arg1, arg2, ...)" function call interpolation. We use the "env" function to access definitions in the process environment. These two extensions allow us to put common configuration files under version control and reuse them across instances. If necessary, an instance can use "%redefine" or define envvars to override values in the common configuration file as necessary. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On Fri, Jan 05, 2007 at 06:07:08PM +0100, Brian Sutherland wrote: > > That's interesting. As a developer, I like things to be > > self contained. Most Unix system administrators I know want me > > to follow standard Unix file-system layour conventions (e.g. > > http://www.pathname.com/fhs/). > > Wearing my sysadmin cap, I'd like to say +100 to following the FHS. Note that there are minor differences to the 'man hier' manpage on FreeBSD... -- __ "Nothing is as subjective as reality" Reinoud van Leeuwen[EMAIL PROTECTED] http://www.xs4all.nl/~reinoud __ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martin Aspeli wrote: ... Anyway - I hope these perspectives are useful. I'm certainly not disagreeing with what you're saying or with the direction you're pointing out. I think we just need be mindful that there were some good things about the past approaches as well as problems (not that you're not). I think we're in strong agreement. I think we need both the Framework and the apps that use the Framework, including Zope2/Plone-style pluggable apps. I think we need to keep these efforts somewhat distinct though. I'd love to see projects that focus on building killer apps on top of the Zope 3 framework. I just want people to understand that the application != the framework. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On Fri, Jan 05, 2007 at 10:29:03AM -0500, Jim Fulton wrote: > Reinoud van Leeuwen wrote: > > On Wed, Jan 03, 2007 at 05:12:18PM -0500, Jim Fulton wrote: > >> Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances > > [...] > >> I should note that there have been a number of sucessful Zope 3 > >> applications that were not the OFS. In fact, some of the earliest > >> production Zope 3 applications were not based on the OFS. > > > > One of the first Zope 3 applications I looked at was SchoolBell. I was > > charmed by the elegant structure after install: a bunch of libraries > > somewhere, and a single instance directory containing a configuration file > > (for SchoolBell only, not Zope), and start and stop scripts. The Data.fs > > file was built during the first run. > > Where did log files end up? How about the zademon socket file? There is no zdaemon socket file, the server is daemonized using the -d option. Instances can be created and the logs are stored as in Zope3. Providing daemon start/stop capability is left up to operating system tools. As a packaged distribution (dpkg) the daemon control is a standard lsb compliant shell script that calls start-stop-daemon. Note that schooltool only really supports production use as a packaged application at this point. > > As a system administrator, this is how I like to see applications. > > That's interesting. As a developer, I like things to be > self contained. Most Unix system administrators I know want me > to follow standard Unix file-system layour conventions (e.g. > http://www.pathname.com/fhs/). Wearing my sysadmin cap, I'd like to say +100 to following the FHS. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote:
>
> I'll make some small comments below, but I want to make a big
> comment to start. Zope 2 and Plone are both examples of
> extensible applications. In my note, I was trying to make the
> point that I think such applications have value. I'd like to
> see them exist. I'd like to see them done well. I think Zope 2
> did it very well, in it's time. I think Plone and other applications
> have carried that forward successfully.
>
> At ZC, for better or worse, we are no longer in the business
> of applications that are extensible in that way. We build
> applications that are used directly by our customers.
> I think this is true of many Zope developers. *We* use Zope 3
> as a library for building applications.
>
> Both uses are valuable and should be supported.
>
> The application that I've been referring to as the "OFS"
> (again, a more or less random name) is a pale imitation of
> Zope 2.
>
This is very much what I read into your comments and I think it is an
impotant architectural decision whether we're building an application or a
framework (Plone itself struggles with that decision sometimes); The strong
"framework" leaning that Zope 3 has adopted is probably to its benefit, and
is almost certainly the main reason why we are able to benefit from Zope 3
at all today in the Plone universe (via Five).
However, Zope 3 should not be and is not just a library that ZC and a few
other people with deep investment in the framework use for their
applications. To grow, stabilise, mature and become a good vehicle for
selling work ("I trust you because you're using Zope 3", rather than, "I
don't trust you becuase you're not using J2EE") the community needs a
constant influx of new developers and interested parties - the first
instance, users of the framework.
The general direction that web frameworks are moving in, led by Rails and to
a certain extent Django, Pylons, TurboGears and arguably Plone in some
circumstances, is that getting started must be quick, results must be rapid,
the tools must support "agile" working practices and the learning curve must
be managable. Most people don't have the time to bet that reading a book or
two will be worth the investment (of time) before they start doing something
useful and productive.
This to me is where we can learn from the success that Zope 2 and Plone have
enjoyed (or been the victim of, as it may be architecturally speaking). The
main reason people think about building applications "in Plone" at all (a
somewhat self-contradictory notion) is that if they can re-use all the
pretty UI and HTML/CSS primitives and user management and navigation
elements and security and workflow from Plone, turning off the portlets and
content types and junk they don't need and turning on the custom
look-and-feel and extra content types and portlets and forms they *do* need,
they get something up and running quicker, to a higher standard, than if
they start from a palette of components and a blank .py file.
In other words, as Martijn has said, I believe it is very important for the
community to support meaningful distributions/app servers/higher level
frameworks (singular or pural) that show off what Zope (3) is good at and
how it's done, that can be customised and (this is where the CA approach
really kicks ass) where future upgrades to this means you benefit, not that
you need to re-fork it for your own needs.
I would be worried if I felt that the Zope 3 community became only about
components and left this "real world but generic assembly" work to "someone
else" when no "someone else" would be interested or skilled or emotionally
invested enough to care. In the Plone world, we have the focus of
Plone-the-application that implies we have to make Plone-the-framework
better. If things become *too* scattered, where is the focus of Zope3?
(note: I'm exaggerating here, I think things are moving in the right
direction not the wrong one, I'm just playing devil's advocate and exploring
what I've seen from the Plone side of the fence)
> Note that there is nothing inherently hierarchical about ZODB.
> Of course, ZODB makes modeling hierarchies (and other graphs) much easier
> in many ways that working with non-object databases.
>
> Of course, I'm a big fan of the ZODB and would use it for all sorts of
> "non-content-centric apps", whatever that means. :)
>
Like I said, I'm quite tainted by Zope2/CMF/Plone. I like to model
(many/some) problems as hierarchical data structures with concepts like
one-to-many relationships as folders with content. I agree the ZODB isn't
necessarily hierarchical, but all the use cases I've ever seen for it have
been. :)
> Well, fortunately, thanks to setuptools and tools like easy_install and
> zc.buildout, you should only need one trip to the cheese shop (or
> wherever)
> and the dependencies should come along automatically. I'm also working
> on ways to automate packaging and app and all of it's dependencies
> together.
>
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
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 -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Reinoud van Leeuwen wrote: On Wed, Jan 03, 2007 at 05:12:18PM -0500, Jim Fulton wrote: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances [...] I should note that there have been a number of sucessful Zope 3 applications that were not the OFS. In fact, some of the earliest production Zope 3 applications were not based on the OFS. One of the first Zope 3 applications I looked at was SchoolBell. I was charmed by the elegant structure after install: a bunch of libraries somewhere, and a single instance directory containing a configuration file (for SchoolBell only, not Zope), and start and stop scripts. The Data.fs file was built during the first run. Where did log files end up? How about the zademon socket file? As a system administrator, this is how I like to see applications. That's interesting. As a developer, I like things to be self contained. Most Unix system administrators I know want me to follow standard Unix file-system layour conventions (e.g. http://www.pathname.com/fhs/). Needs vary of course. For large scale applications like the ones we build, we need many instances for both scalability and redundancy. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
I'll make some small comments below, but I want to make a big comment to start. Zope 2 and Plone are both examples of extensible applications. In my note, I was trying to make the point that I think such applications have value. I'd like to see them exist. I'd like to see them done well. I think Zope 2 did it very well, in it's time. I think Plone and other applications have carried that forward successfully. At ZC, for better or worse, we are no longer in the business of applications that are extensible in that way. We build applications that are used directly by our customers. I think this is true of many Zope developers. *We* use Zope 3 as a library for building applications. Both uses are valuable and should be supported. The application that I've been referring to as the "OFS" (again, a more or less random name) is a pale imitation of Zope 2. Martin Aspeli wrote: Jim Fulton wrote: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances I found this very interesting. As more of an indirect consumer to Zope 3 (but user of Zope 3 via Five and developer of Plone on Zope 2), here are some of my own thoughts. In the Zope2/CMF/Plone world, we are used to Zope instances that may host several sites (e.g. Plone instances). We find that users like to be ablet to have multiple sites (possibly on muiltiple URLs via RewriteRules) and manage a single instance of the app server (Zope 2) on their machine. One-process-and-port-per-application is certainly *perceived* to be more resource intensive and difficult to manage if there are multiple appilcations on one server. Zope 2.10 has been a huge improvement in that regard. The local component registry work has made "site-ness" and local/ZODB-persisted configuration much, much easier. Plone 3 is benefting immensely from this as we speak. We also find that users expect to be able to deploy Plone (a bunch of products in a tarball that extracts to the Products/ directory) and various add-ons (other products) easily. This was one of the things that confused me most when learning about Zope 3. Am I supposed to put application-specific ZCML files in an "instance-global" package-includes? Should I tell people to edit those ZCML files during deployment (oh Java hell)? Should all the components of the application be eggs in the global PYTHONPATH or in the instance home? The second thing that confused me was the role of the ZMI/OFS. In Plone, we have an application that builds on top of Zope2-the-application, then CMF and then Plone's own layers of code. People who develop solutions based on Plone typically treat Plone itself as another application/framework hybrid and customise Plone (using the customisation mechanisms Zope 2 and CMF provide) to their own needs in terms of look-and-feel and functionality. This may not always be architecturally the best idea, but it often makes people very productive, very quickly. If I were building a plain Zope 3 application, I still don't know if I'd want to use the browser menus, folder listings etc of the ZMI and just tweak the look and feel, or if it would be better to start from scratch (though I haven't yet built a plain zope 3 app from the ground, so it may just be ignorance on my part). Certainly, if I had to understand most of zope.* to be able to build my own zope.app.* from scratch, the learning curve may just be too much. Now, I still think Zope (2 and 3) has the most benefits in content-centric use cases. I could see ways to build an application using Zope 3 views and traversers and other components without using the ZODB at all, but I imagine it'd be a lot of work to get going if I didn't have the fundamentally hierarchical nature of the ZODB, Note that there is nothing inherently hierarchical about ZODB. Of course, ZODB makes modeling hierarchies (and other graphs) much easier in many ways that working with non-object databases. Of course, I'm a big fan of the ZODB and would use it for all sorts of "non-content-centric apps", whatever that means. :) mapping its nodes to my application's URLs. I'm sure that is just because I'm tainted by the way I think about Zope 2 and Plone, but it's non-obvious to me how a completely non-contentish Zope 3 application would work; or rather, I think it would be easier to use Pylons or Django or TurboGears in that case, if I were building something that needed a couple of simple forms and a few static pages and a big database behind it. There are certainly not many non-contentish applications to use as examples. I think your thoughts resonate quite well with my own observations and/or confusion. I would, however, caution against becoming over-zealous in breaking things up. Zope 2, CMF and Plone are successful in large part because people get started quickly. If it takes fifteen trips to the cheese shop to understand how to get a page to say Hello world, I'm not sure people would bother. Well, fortunately, thanks to setuptools and tools like easy_in
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
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? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
I'll be happy to see the complete eggification - the sooner the better. The only issue I see as a possible negative is that it may be hard for folks to visualize z3's potential. AFAIK the framework approach has not negatively impacted Twisted that has some documentation and a book but no core app. The pattern for package construction in z3 is getting clearer all the time but folks will certainly need to work to see z3's advantages. Maintaining an eggified app, whether folks want to build on it or learn from it, is likely still relevant to the future of z3. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
> Behalf Of Jim Fulton > Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances [...] > Of course, I'll release these recipes when I have them. > I think that's a good idea and we will use them. Probably we write our own recipes in our projects (if we understand them). But I also think a very important part for the comunity is to develop something like a application server as a product. Regards Roger Ineichen _ END OF MESSAGE > > Jim > > -- > Jim Fultonmailto:[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 > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On Wednesday 03 January 2007 17:12, Jim Fulton wrote: > In summary, I'm seeing Zope 3 applications as separate entities from > the OFS. The OFS application isn't something we'll use directlty. > Instances will be instances of our applications, not of Zope 3. > > I should note that there have been a number of sucessful Zope 3 > applications that were not the OFS. In fact, some of the earliest > production Zope 3 applications were not based on the OFS. The short answer is that your experience reflects mine. I too think that the OFS (or the ZMI how I usually call it) is not useful, and I personally do not reuse their UI components either. However, as you also pointed out, we use a lot of the packages that were developed for the OFS. Honestly, I would not be sad to see most of the UI code in zope.app go away. We rarely use it, since we use Python code to configure local components and do not even write/register views for the OFS/ZMI in our applications. On the distribution side, I really do not have much experience. I can only say that we still use package-includes, but I usually develop Makefiles (or BAT scripts in Windows) that remove the package ZCML files that we do not need. I can easily see myself switching to a different pattern here, as it seems to have the same effect. (I really hope that Roger Ineichen or Bernd Dorn are speaking up about deployment, since they do the deployment for the applications I was working on.) As to packaging, I hope that once we are using eggs, we will have more than one Zope 3 distribution. One that is the official Zope Foundation one, perhaps a security-certified one, and one with many bells and whistles included (i.e. many of the z3c, zc, etc. packages). This will give newcomers nice entry points. When we develop our own applications, we will create different distributions. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On Wed, Jan 03, 2007 at 05:12:18PM -0500, Jim Fulton wrote: > Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances [...] > I should note that there have been a number of sucessful Zope 3 > applications that were not the OFS. In fact, some of the earliest > production Zope 3 applications were not based on the OFS. One of the first Zope 3 applications I looked at was SchoolBell. I was charmed by the elegant structure after install: a bunch of libraries somewhere, and a single instance directory containing a configuration file (for SchoolBell only, not Zope), and start and stop scripts. The Data.fs file was built during the first run. As a system administrator, this is how I like to see applications. -- __ "Nothing is as subjective as reality" Reinoud van Leeuwen[EMAIL PROTECTED] http://www.xs4all.nl/~reinoud __ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote: > > Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances > I found this very interesting. As more of an indirect consumer to Zope 3 (but user of Zope 3 via Five and developer of Plone on Zope 2), here are some of my own thoughts. In the Zope2/CMF/Plone world, we are used to Zope instances that may host several sites (e.g. Plone instances). We find that users like to be ablet to have multiple sites (possibly on muiltiple URLs via RewriteRules) and manage a single instance of the app server (Zope 2) on their machine. One-process-and-port-per-application is certainly *perceived* to be more resource intensive and difficult to manage if there are multiple appilcations on one server. Zope 2.10 has been a huge improvement in that regard. The local component registry work has made "site-ness" and local/ZODB-persisted configuration much, much easier. Plone 3 is benefting immensely from this as we speak. We also find that users expect to be able to deploy Plone (a bunch of products in a tarball that extracts to the Products/ directory) and various add-ons (other products) easily. This was one of the things that confused me most when learning about Zope 3. Am I supposed to put application-specific ZCML files in an "instance-global" package-includes? Should I tell people to edit those ZCML files during deployment (oh Java hell)? Should all the components of the application be eggs in the global PYTHONPATH or in the instance home? The second thing that confused me was the role of the ZMI/OFS. In Plone, we have an application that builds on top of Zope2-the-application, then CMF and then Plone's own layers of code. People who develop solutions based on Plone typically treat Plone itself as another application/framework hybrid and customise Plone (using the customisation mechanisms Zope 2 and CMF provide) to their own needs in terms of look-and-feel and functionality. This may not always be architecturally the best idea, but it often makes people very productive, very quickly. If I were building a plain Zope 3 application, I still don't know if I'd want to use the browser menus, folder listings etc of the ZMI and just tweak the look and feel, or if it would be better to start from scratch (though I haven't yet built a plain zope 3 app from the ground, so it may just be ignorance on my part). Certainly, if I had to understand most of zope.* to be able to build my own zope.app.* from scratch, the learning curve may just be too much. Now, I still think Zope (2 and 3) has the most benefits in content-centric use cases. I could see ways to build an application using Zope 3 views and traversers and other components without using the ZODB at all, but I imagine it'd be a lot of work to get going if I didn't have the fundamentally hierarchical nature of the ZODB, mapping its nodes to my application's URLs. I'm sure that is just because I'm tainted by the way I think about Zope 2 and Plone, but it's non-obvious to me how a completely non-contentish Zope 3 application would work; or rather, I think it would be easier to use Pylons or Django or TurboGears in that case, if I were building something that needed a couple of simple forms and a few static pages and a big database behind it. I think your thoughts resonate quite well with my own observations and/or confusion. I would, however, caution against becoming over-zealous in breaking things up. Zope 2, CMF and Plone are successful in large part because people get started quickly. If it takes fifteen trips to the cheese shop to understand how to get a page to say Hello world, I'm not sure people would bother. Most likely, that's solved by having use-case focused (and real-world tested) bundles or distributions that provide meaningful functionality of starting points. It's also solved by having some customisable "best-practice" components that are closer to the user. Learning from such examples is probably the main way people pick up new technologies and conceptualise how they can solve their particular use cases. Martin -- View this message in context: http://www.nabble.com/Some-thoughts-on-Zope-3%2C-Zope-3-applications%2C-and-Zope-3-instances-tf2916344.html#a8157025 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances I'd like to share some thoughts about what Zope 3 is (to me), what a Zope 3 application is, and what a Zope 3 instance is, or should be. I think this should influence our thinking about Zope 3 releases and tools we create, like zc.buildout and builout recipes, that help build and deploy applications. First some background. Zope 2 was first and foremost an application. It was extensible and people could build applications on top of it, but that was through an extension mechanism. Over time, greater and greater emphasis was placed on building applications on top of it. I think it was and remains a pretty useful application. I'd love to see a similar application built using Zope 3. Perhaops that application will be Zope 2 someday. :) Zope 3 was designed first for application developers. It was always envisioned as a collection of components that could be assembled and combined with other components in a variety of ways. In this way, Zope 3 is more like a library (actually a set of frameworks and libraries) than an application. The current Zope 3 distribution also contains an application that resembles Zope 2 in many ways. There is an object tree and a Zope Management Interface. At least up to now, when you install a Zope 3 distribution, you get an application that you can run out of the box, for whatever that's worth. In this document, I'll call this application the the Object Filing System (OFS). I've found the OFS to be useful when developing Zope 3 itself. The OFS was really the first application developed with Zope 3. There are also certain kinds of applications that can use the OFS as a starting point. We've built content-management systems that reuse much of it. In the later case, we've used it less as an application than as a library. It's not obvious to me that that the OFS has much value as an application in it's current form. For the last year, I've been working on supporting some older applications in our hosting environment. In doing that, I've come to appreciate some aspects of large scale application deployment: - Deployments have to be highly automated. (We are moving toward deploying applications as RPMs in our hosting environment. These RPMs are created using zc.buildout and include the applications and tools for creating application instances.) - Deployments like the ones we do, have many (tens of) instances of the same application. - Applications need to be highly manageable. Among other things, this means that application artifacts, like software, configuration files, log files, and so on should be in predictable, easy to find locations. (e.g. http://www.pathname.com/fhs/) mkzopeinstance doesn't serve these needs very well. It is a bit hard to automate, as it isn't as flexible as needed to define many application parameters. When many instances are used, there tends to be a lot of duplication. An extreme case of this is the package- includes directory (or the Zope 2 Products directory). The instance directories distribute files in ways that Unix system administrators find hard to deal with. When dealing with many instances, I too have found the traditional instance directory layout hard to deal with in production. One of the problems with traditional zope instances is that they combine application definition with instance configuration. For example, a Zope 3 instance created by mkzopeinstance includes lots of ZCML files, in the form of generated ZCML files such as site.zcml, and the contents of package-includes. It also contains a number of generated scripts. This information is nearly identical accross instances of the same application. My current thinking, FWIW: It's not clear to me that the Zope 3 application we now distribute has much value. I'd be interested to hear other people's thoughts on this. I'd like to see some popular Zope 3 applicaton or applications that people download and use to get excited about Zope 3. I don't know if anyone is developing something like that. I hope they are. I don't think anybody is trying to turn the existing OFS into an application like that. If Zope 3 is really primarily a library, then maybe we should distribute it that way, as eggs or as setuptools aware source distributions. Zope Corporation is creating applications with Zope 3. While these applications use many of the components from the OFS, they are not the OFS, nor are they extentions of the OFS. We don't use package- includes. Rather we define an application package that has a ZCML file that includes ZCML files for the packages we use. In the future, our application packages will have setuptools-style package dependencies on the packages they use. The traditional Zope 3 distribution won't be useful to us. I'd like to separate application def
