[Zope3-dev] Builbot mail not working ?
Hi, Can anyone verify that buildbot [1] send test failure error mails to list? There is one test failure in Zope 3 trunk now [2]. But it's not in Zope3-dev list archive [3]. [1] http://buildbot.zope.org [2] http://buildbot.zope.org/Zope3%20trunk%202.4%20Linux%20zc-buildbot/builds/832/test_2/0 [3] http://mail.zope.org/pipermail/zope3-dev/ Regards, Baiju M ___ 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
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
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martin Aspeli wrote: [snip] 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. +1 here. Just splitting stuff up into little flexible pieces won't attract people. If our goal is to attract Zope 3 developers we need to make it easy to get started. We can also say that Zope 3 is componentized and flexible and all that, and this will attract developers too, but if the first bit is too hard all our talk about flexibility will lead to nothing. So, we need to do both: make it easy to get started, and componentizing for greater flexibility later. If we just do the first, we make Zope 2 style mistakes and end up with a monolithic system that should be easier to develop with. If we just do the latter, we make Zope 3 style mistakes and end up with a well componentized system that isn't used a lot. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote: [snip] 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. In development I've typically used bits and pieces from the OFS as a library. That is, I used the OFS components but didn't care much about the ZMI user interface on top of it. I'm not sure whether your OFS is my ZMI, but I'll talk about the ZMI here in the hope it's close enough to what you mean. If not I hope my discussion is valuable in its own right. :) I do think there is room for a management interface that allows you to inspect object state and do some simple configuration, but it should be focused narrowly and not aim to be an TTW application development environment or content management system or a reusable user interface framework. We are hoping to develop a management interface like that for Grok at some point (I'm currently in Germany for grok sprint 2). [snip] 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. I'd like to rephrase this and say I don't think (or hope) that someone is trying to turn the existing Zope 3 ZMI into an application like that. I like having simple base classes like Folder and File around that I can reuse or inherit from. We're hoping to supply these with Grok though. Something OFS-like and simple would have its place in my view of the terminology. :) While I fully support Zope 3 becoming a library and toolbox of reusable bits, I also want to emphasize that it's very important for Zope 3 to have obvious ways to do things, preferably one obvious way to do it. Of course the underlying system should be flexible, but the code that people will be reading should be clear and easy to understand. This is where popular Zope 3-based applications come in: they serve as sample code for the applications following them (no matter whether they want to be sample code or not). [snip] 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 think this pattern is a good approach. I do think that it is valuable to emphasize that each instance has some common features: you could for instance support a debugging or management UI that can be optionally enabled for each of them. This allows for commonality and also the feeling that people get more out of the box than a lot of tools they may not know how to apply effectively. 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. :) The current ZMI is currently doing some things for us (however badly), so we should analyze what it does: * first user experience. I install zope 3 and can vaguely click around the ZMI. Not much, but at least I have the feeling what I installed works and is doing obscure things. * it is a user interface that helps with installing applications. Multiple instances of an application may be deployed under the same port number. I think this is a valuable feature, and allows the possibility for multiple cooperating applications without having to open new ports for each of them. You can use the ZMI to install multiple Document Library instances, for instance. * it's an introspection and debugging interface. My application is broken during development and deployment and I can go into the ZMI and see what's wrong. I can look at various local configuration settings. * it can be a configuration interface. Not only complicated stuff like installing local utilities, which I hope can move mostly to declarative code instead, but also simple stuff like which exceptions are logged can be configured. What else? We should figure out what we want to (and can
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
