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_install
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
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
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
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 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
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
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
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
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
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
