Re: [Zope3-dev] Two visions
On Mar 6, 2006, at 9:21 PM, Jake wrote: I think it is a huge mistake to lose Zope branding. After years of building up momentum behind a project, to head off into some strange developer code speak is just going to lose people who are not intimately involved. The world, after many years, gets versions. Stick to it. Works: Mac OS9 - Mac OSX (10) Here was a mistake: Mosaic - Netscape - Netscape Communicator - Netscape Gold - Firebird - Mozilla - Firefox Considering Firefox has nearly 15% marketshare today, I'd call it a success. It certainly could have been worse had Netscape not done the hail mary of releasing it under another name that wasn't conflated with its own brand (witness the takeup rate of Netscape 6/7). - C ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
On Mar 7, 2006, at 6:56 AM, Chris McDonough wrote: On Mar 6, 2006, at 9:21 PM, Jake wrote: I think it is a huge mistake to lose Zope branding. After years of building up momentum behind a project, to head off into some strange developer code speak is just going to lose people who are not intimately involved. The world, after many years, gets versions. Stick to it. Works: Mac OS9 - Mac OSX (10) Here was a mistake: Mosaic - Netscape - Netscape Communicator - Netscape Gold - Firebird - Mozilla - Firefox Considering Firefox has nearly 15% marketshare today, I'd call it a success. It certainly could have been worse had Netscape not done the hail mary of releasing it under another name that wasn't conflated with its own brand (witness the takeup rate of Netscape 6/7). - C Considering it is a product that was around for 15 years, spent tons on advertising (which I helped pay for) and has a global, geek appeal, I think it was a slight success. Since we don't know how much better off it would have been by keeping one of the other 5 names it had, which actually had brand recognition, we will never know. Jake http://www.ZopeZone.com Zoping for the rest of us ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
On Feb 28, 2006, at 7:39 AM, Martijn Faassen wrote: So, my proposal would be to tone down the vision to what we have already: a co-evolving Zope 3 and Zope 2, with Zope 2 following and Zope 3 leading (or Zope 2 driving Zope 3 forward, however you want to see it). No renaming necessary. No change of course necessary. Zope 2 can stick to Zope 2 features as long as necessary so there's no rush to replicate Zope 2 functionality in Zope 3 any time soon. At the same time, Zope 2 requirements can drive the evolution of Zope 3. I know I sound conservative here, but I'm actually happy with the way things are working now. Let's not fix what isn't broken. We can make incremental steps to making it better, and I'm glad people are starting to understand the ideas behind Five, but I don't see the need for a change of direction. Regards, Martijn +1 Jake http://www.ZopeZone.com Zoping for the rest of us ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
On Tuesday 28 February 2006 06:51, Martijn Faassen wrote: snip great discussion I think we can just carry on this message. I could not agree more. I have nothing to add at this point. 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] Two visions
On Wednesday 01 March 2006 00:33, Jeff Shell wrote: All of these big features are neat and well. But I want less. I don't know how to use less. There are dependencies on zope.app creeping into packages allowed in zope.*, and I understand that more of that is likely to happen in the future. And that terrifies me. Don't be. :-) It is the first step of actually making zope.app *much* smaller. This in turn will mean that you might be able to develop apps without relying on zope.app at all, which is better for you, since you can control the installed components better. I think by finding a good packaging solution and staying the path of reducing zope.app we will achieve what you want. :-) 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] Two visions
On Tuesday 28 February 2006 07:39, Martijn Faassen wrote: I know I sound conservative here, but I'm actually happy with the way things are working now. Let's not fix what isn't broken. We can make incremental steps to making it better, and I'm glad people are starting to understand the ideas behind Five, but I don't see the need for a change of direction. A strong +1. Wow, I agree with Martijn for three posts in a row; that has not happened for a long time. :-) 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] Two visions
Jeff Shell wrote: Perhaps it's not the greatest name, but I've become enamored with *lib names like 'formlib'. 'zopelib' Hmmm. Not the prettiest thing. But it does say Zope Library. If that becomes the *core* of the mythical Zope 5, awesome. This sounds familiar. :-) http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopeLibPackage Unfortunately, this discussion is too fuzzy for me to understand exactly what's being proposed. How about something concrete: will the Zope 3 in vision #2 have a ZMI, and will typical ZODB objects have a __parent__ and __name__? (Either yes or no is fine, but maybe or sometimes is a lot harder to interpret.) Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
Jim Fulton wrote: I'd like to get feedback on two possible visions for the future of Zope 2 and Zope 3. 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 [snip] 2) In an alternate vision, Zope 2 evolves to Zope 5. [snip] Thoughts? My initial reaction is: don't change the names (or at least be extremely careful about this). Zope 3 has a brand and we'd risk throwing it all away. We also risk being seen as wavering on the course. I don't see the two proposals as mutually exclusive, and I think both are true right now. Zope 3 is replacing Zope 2 for some new applications. Zope 2 is evolving towards Zope 3 for existing applications. I wrote a piece of text about the relationship between Zope 2 and Zope 3 that might help in this discussion: [snip section about Zope being mature] Going forward - We are applying our hard-earned lessons by making Zope better. The web is evolving and so is Zope, continuously striving to further increase Zope's power, flexibility and functionality. A visionary project was started in 2001 to build the next generation of Zope software, `Zope 3`_. Zope 3 uses powerful component technology to further increase the already strong extensibility and flexibility of the Zope platform. The Zope 3 project is benefiting in this from the deep experience of a large community of Zope 2 developers. Zope 2 is not being left behind however: the Zope community initiated a project called Five_ (2 + 3) to bring Zope 3 technology, where mature technology is ported back into the Zope 2 platform to obtain the best of both worlds. Zope 2 now contains Zope 3 technology and will go forward on this path with every release, while Zope 3 is forging ahead to explore new possibilities. Zope 2 and Zope 3 are evolving together this way, both benefiting from each other's strengths, until the differences between the two eventually disappear. Zope 2 and Zope 3 - Zope comes in two flavors, Zope 2 and Zope 3. Zope 2 is a mature, compatible and reliable platform that supports an enormous amounts of features. It's the workhorse of our community. Zope 3 provides a powerful component architecture and a clean, elegant architecture that is a developer's dream. It's our community's thoroughbred. It can be hard to choose between the two. Eventually you won't have to as they're evolving towards each other [Going Forward]. But how do you choose now? Here are some rough guidelines: If you are a hard-core developer, looking for power and flexibility in a clean architecture, and if you are building a new web application, you may want to consider Zope 3. If you want to make use of the rich variety of powerful Zope 2 software, need community, support and stability, consider Zope 2. And don't forget that with the Five_ (2 + 3) project, you can already start using Zope 3 technologies from within the safety of Zope 2. Whether you choose Zope 2 or Zope 3 for your project, you will reach the same future, just by a different path. Which path is better for you we leave up to you. I think the right way to go forward is to stay the course on this. Zope 3 is the future of Zope 2. Zope 2 will continue to evolve in the direction of Zope 3, while Zope 3 forges ahead. The difference between themselves will eventually disappear. Perhaps what I'm describing is already what you describe for Zope 5. I just don't see the reason to actually change the names, or to imply that Zope 3 does *not* have a future as a platform to build on, which could be seen as an implication of going with Zope 5. Changing names and version numbers around is not going to help anyone very much and I think could in fact be damaging. I think we're actually reaching some clarity of where we are going, people are starting to get the idea, and we just need to communicate it better to the wider world, not change our message. The pent-up demand for Zope 3 technology from Zope 2 developers that existed for a long time in the Zope 2 world while Zope 3 was under development has now been safely channeled into Five-related projects - people can actually use Zope 3 technology right now and worry less about the future. The meme Evolution not revolution which I have tried to spread along with Five has taken hold in the various Zope subcommunities. Here's some more of what I wrote: :Q: What's Zope? What's it good for? :A: It's a web application platform that can be used to build web applications, CMSes, etc. :Q: Where's zope coming from? is this some new thing? :A: No, it's mature. We got tons of experience and community and stuff. :Q: By 'mature' do you mean Zope is old cruft? :A: Nope, it's going forward, and has been working on this for years. (Zope 3) :Q: Well what's all this Zope 2 and zope 3 then? should I worry? :A: Nope, we are managing this, you can use either, and get the benefits of both. (Five) I think we can just carry on this message.
Re: [Zope3-dev] Two visions
Hey, I have another comment about Zope 5, sparked by something Jeff Shell wrote. Currently we have a clear path to evolution. Zope 3 evolves at its pace, and Zope 2 evolves mostly by catching up with Zope 3, replacing more and more bits with Zope 3 bits, which often takes considerable ingenuity. We have shown that we have enough developers to sustain this both for Zope 3 and Zope 2 development. We know how to do it. Any shift to a Zope 5 vision where Zope 3 and Zope 2 are profiles of the same application would require a considerable investment of development time that we don't have, or alternatively, endless waiting. Zope 5 will in fact be very similar to one interpretation of the dreaded X in Zope X3: a version of Zope 3 that's backwards compatible with Zope 2. I'm skeptical about ever getting this done in revolution style development, and holding it up as the future will prompt remarks like When is Zope 5 going to be done? while nobody is actually doing anything about it. This is very very bad marketing. I really really want to avoid a repeat of history here... Meanwhile, I think the current path gets us to a future where the difference between Zope 2 and Zope 3 will become less, and it will be more and more possible to write Zope 3 applications in Zope 2, and more and more Zope 2 pieces will be replaced with pieces from Zope 3. This vision has been sold to the community already and we're on track. So, my proposal would be to tone down the vision to what we have already: a co-evolving Zope 3 and Zope 2, with Zope 2 following and Zope 3 leading (or Zope 2 driving Zope 3 forward, however you want to see it). No renaming necessary. No change of course necessary. Zope 2 can stick to Zope 2 features as long as necessary so there's no rush to replicate Zope 2 functionality in Zope 3 any time soon. At the same time, Zope 2 requirements can drive the evolution of Zope 3. I know I sound conservative here, but I'm actually happy with the way things are working now. Let's not fix what isn't broken. We can make incremental steps to making it better, and I'm glad people are starting to understand the ideas behind Five, but I don't see the need for a change of direction. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
Martijn Faassen wrote: So, my proposal would be to tone down the vision to what we have already: a co-evolving Zope 3 and Zope 2, with Zope 2 following and Zope 3 leading (or Zope 2 driving Zope 3 forward, however you want to see it). No renaming necessary. No change of course necessary. Zope 2 can stick to Zope 2 features as long as necessary so there's no rush to replicate Zope 2 functionality in Zope 3 any time soon. At the same time, Zope 2 requirements can drive the evolution of Zope 3. An emphatic +1. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
Gary Poster wrote: [snip] On Feb 28, 2006, at 10:06 AM, Philipp von Weitershausen wrote: I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers. ...if the single app server is based on acquisition, __bobo_traverse__ and friends, objectValues and friends, ZCatalog, and so on, I'd rather have two, thanks: at least I can have one I like. I can see where Philipp is coming from: yes, it would be good to collapse the Zope 2 and Zope 3 communities into one if that frees up more development resources and lets us do less duplicate work. This cannot however be done by big steps or mandate or changing names, and this is where I think I disagree with Philipp somewhat. We're on the right track already. The communities are merging into a single community. Just compare today with the situation just one year ago - massive changes everywhere, and positive ones. Merging communities can be done by making it easier for people from the communities to work together (for instance by working on Five) and by evangelizing (you can use Zope 3 in Zope 2, today). It's fairly subtle work and it takes a long time. Philipp is doing great on all these fronts and without him Five wouldn't be where it is today. I just don't understand how the current zed/Zope 5 proposals would make everything go faster or be easier or be clearer... Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
On 2/28/06, Martijn Faassen [EMAIL PROTECTED] wrote: Gary Poster wrote: [snip] On Feb 28, 2006, at 10:06 AM, Philipp von Weitershausen wrote: I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers. ...if the single app server is based on acquisition, __bobo_traverse__ and friends, objectValues and friends, ZCatalog, and so on, I'd rather have two, thanks: at least I can have one I like. I can see where Philipp is coming from: yes, it would be good to collapse the Zope 2 and Zope 3 communities into one if that frees up more development resources and lets us do less duplicate work. I still fear collapsing them into one. This is no offense to any of the hard work people are doing on all projects. Someone said Zope 2 + Zope 3 + Five is big complexity, and I agree. A lot. It's easier for us to use only one or only another. I prefer Zope 3. It's simpler. But already there are some design decisions that have happened in recent months that make me less comfortable about that. All of these big features are neat and well. But I want less. I don't know how to use less. There are dependencies on zope.app creeping into packages allowed in zope.*, and I understand that more of that is likely to happen in the future. And that terrifies me. An acknowledged Zope 2 problem is the large inheritance structure that objects have to support to be useful and usable, and that it creates a tight coupling that can't be broken. But having a large collection of loose couplings that can't easily be broken is not a better solution. Having to load up and configure 80% of the zope library to use 30% of its features isn't tenable. The size of Zope 3 app server as it stands now is still overwhelming to me. I think we could still stand to do with some smaller cleaner core features first. The part of this vision that worries me tonight is that it gives priority to the Big Complex Application Server With All It's Features (as good as they may be). Instead we could do good by giving that thing a better base to use, and benefit others among us by having a better base to use with less overhead (says the man bit by ZCML browser dynamic class generation again today). IE - move some of the *core* widget concepts out of zope.app and into formlib, and finding ways of severing the zope.app dependency from zope.formlib. Move some of the core interfaces up a level, and make the ones in zope.app.form extend those core ones. If application server (still a term I'd like to see defined in this context) becomes a priority, or a separate priority, or we just start thinking about what needs to be done to make core things simple, powerful, and sharable; and how to build the Application Server on that to give people a variety of development/deployment options or pre-built tools to help with so-called large applications then I think this could be a good thing. But if it all becomes one big overwhelming library/server/solution again, I can't stick around for that. I don't need something with the weight of Plone or the CMF to make an itinerary manager. Super terrific content management tools aren't going to help me build a state heavy e-commerce application. Getting too tied up in the concepts of containers/containment/all objects are like this mentality isn't going to help us deliver a sprawling enterprise payroll management system from five different data sources. The loose coupling of Zope 3 makes doing these different systems in Zope using a similar development technique for each possible. I want to make sure that the loose coupling remains useful and usable, that trying to use a particular widget isn't likely to make my system need to register 80 supporting components and sub systems. Hopefully some simple guidelines can stay in place and stuck to in regards to how to make sharable components sharable. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
On Mon, 2006-02-27 at 10:37 -0500, Jim Fulton wrote: I'd like to get feedback on two possible visions for the future of Zope 2 and Zope 3. 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 - There will be lots of overlap between the Zope 2 and Zope 3 lifetimes. (Zope 2 might be supported more or less forever.) - Eventually, the gap between Zope 2 and will become very small. requiring a small leap. In this vision, Zope 3 would have to become a lot more like Zope 2, or we would lose features. -1 2) In an alternate vision, Zope 2 evolves to Zope 5. - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. - Zope 3 will explode. :) For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server. Zope 3 will continue as a project (or projects) for creating and refining these technologies. (It would probably make sense for this activity to to have some name other than Zope. On some level, the logical name would be Z (pronounced Zed :). An argument against Z is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;) Advantages of this vision: - Zope 2 users don't need to leave Zope 2. - Zope 3 doesn't have to reproduce all Zope 2 features. - There wouldn't be confusion about 2 Zopes. It is important that Zope 5 be backward compatible with both Zope 2 and Zope 3, although not necessarily in the same configuration. Many people are building Zope 3 applications today and they should not be penalized. Thoughts? +2 I personally think that one of the great things about what has come out of Zope 3 development: other projects can use the technologies without taking Zope 3 lock stock and barrel. I'd hate to see Zope 3 get more girth and loose future traction because it had to be fully backwards compatible with Zope 2. For those who wish to slowly migrate to using Zope 3 technologies without completely rewriting their software, evolving via Five is a fair approach. To quote a blog I'd read earlier today: Doing little things well is a step towards doing big things better. Allowing others to assist in refining the little technologies which make up Zope 3 can achieve this goal. I would fear this would be impossible if the first vision was followed. Andrew Sawyers Jim ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
My 2 EuroCents: Vision 1 is, I think what is happening at the moment for pragamatic and practical reasons. Drawbacks of this is that we loose the ZopeX3 (Zope3X?) vision of cutting loose from old burdens and take off to new horizons. Vision 2, on the other hand (at least to me in my not-really-started-with-z3-development-yet situation), is a lot more appealing for a variety of reasons, not the least that choosing working development model (zope2 and zope3 for starters, there may be others) becomes a configuration(*) issue. The potential benefits of this approach are very appealing (almost like eating the cake and still having it :), so I vote for vision 2. /dario (*) Configuration in a broad sense: mind model, conf-files, development model, etc... -- -- --- Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. Lyrics applied to programming application design: emancipate yourself from mental slavery - redemption song, b. marley ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
On Monday 27 February 2006 10:37, Jim Fulton wrote: 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 2) In an alternate vision, Zope 2 evolves to Zope 5. As you probably know already, I am -1 on the second proposal, since it will disallow us to finally get rid of the old Zope 2 code. Anyways, since I think the vision has too littel technical detail for my taste, I would really like to see some prototyping before I give my final vote. I just want to be ensured that I do not have to deal with additional overhead (i.e. learn Zope 2 again), but can develop Zope 3 applications as I like it. 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: [Zope-dev] Re: [Zope3-dev] Two visions
--On 27. Februar 2006 21:57:46 -0500 Stephan Richter [EMAIL PROTECTED] wrote: On Monday 27 February 2006 10:37, Jim Fulton wrote: 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 2) In an alternate vision, Zope 2 evolves to Zope 5. As you probably know already, I am -1 on the second proposal, since it will disallow us to finally get rid of the old Zope 2 code. Like it or not...I agree with Jim's vision will just be the reality. As long as we do support Zope 2 we will move more and more Z3 technology into Zope 2 which will strengthen Zope 2. I still do not see that Zope 3 will provide everything we need to build large-scale applications. Having CMF 2.0 and having some future Plone version running on top I don't see that Zope 2 will fade out. Andreas pgpUc3AvCaf1Q.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
On Feb 27, 2006, at 10:37 AM, Jim Fulton wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. Of the two, this seems more believable. It also may be the best we can do. However, I still don't like it. :-) - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. This is reasonable, though I don't love it. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. This gets to the heart of my concern, I guess (see below). Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. You say that one of the advantages of this vision is that There wouldn't be confusion about 2 Zopes. I'm afraid that's wishful thinking, if you want Zope 5 to include a Zope 3-like web configuration. If you are going to pursue a Zope Five and the artist formerly known as Zope 3 vision, in which Zope is a single clear product, then it seems to me that Zope Five should be one or the other, and that's what books should describe. A Zope 2 derivative a la Five makes sense, given Zope's history and current users. More below. - Zope 3 will explode. :) For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server. There are some--Steve Alexander and Canonical, maybe?--who might not care about anything beyond choosing among the bag of technologies. But I assert with the right of speaking loudly (i.e., I have no way to prove this) that there are many who appreciate the bag of components design who still want to buy into some of the Zope 3 as web application server story. For instance, if you mean by a Zope 2-like application server an Object File System approach then I certainly hope you are wrong. Even though I don't care much about the Zope 3 ZMI, Zope 3 encapsulates some web app design decisions I would be loathe to lose. I much prefer the Zope 3 approach to OFS, with __parent__ rather than acquisition wrappers, a dict interface rather than objectValues and friends, and traversal adapters rather than __bobo_traverse__ and friends. If acquisition and all the rest are on the way to being replaced within Zope 2/5, then...yay? but then how is it still Zope 2 backward compatible? They seem core to Zope 2 to me. And the Zope 3 versions of the decisions inform many Zope 3 component designs. Do you mean that the Zope 3 users don't need Zope 2 cataloging and indexing? Surely not, and yet again moving Zope Five to the Zope 3 catalog seems pretty questionable as Zope 2 backward compatible. And I *much* prefer the zope.index/zope.app.keyref/zope.app.intid combo in Zope 3. Do you mean that Zope 3 users aren't looking for a better designed web app than Zope 2, that looks less long-in-the-tooth (as I've seen blogs call Zope 2), that has more industrial-strength flexibility and hard-won design experience than the current crop of competitors? I don't think so: I assert that developers of a certain inclination are attracted to the cleanliness of Zope 3 as a web app, and not as attracted to the cruft that accumulates in an older, very successful project like Zope 2. Some of those are new Zope developers, and some are prominent older Zope developers. Do you mean that Zope 3 users don't want a robust, battle-hardened web publisher like the Zope 2 publisher? I think many do. So, I assert that many Zope 3 users, who are in it for the bag of components, *do* want a web application server. If I'm misunderstanding you, then, as Stephan said, maybe you could explain more. (Almost done, but still more below) Zope 3 will continue as a project (or projects) for creating and refining these technologies. (It would probably make sense for this activity to to have some name other than Zope. On some level, the logical name would be Z (pronounced Zed :). An argument against Z is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;) If this is the plan, then I guess I
Re: [Zope3-dev] Two visions
On 2/27/06, Jim Fulton [EMAIL PROTECTED] wrote: I'd like to get feedback on two possible visions for the future of Zope 2 and Zope 3. 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 - There will be lots of overlap between the Zope 2 and Zope 3 lifetimes. (Zope 2 might be supported more or less forever.) - Eventually, the gap between Zope 2 and will become very small. requiring a small leap. In this vision, Zope 3 would have to become a lot more like Zope 2, or we would lose features. Most people would probably agree that we could stand to use features. The warring factions break out over which features to lose. I never thought about this as the potential destination for the Zope 3 replaces Zope 2 vision, but it seems pretty obvious now. I don't think this is a tenable destination. At the least, it's not one that I'd stay on board for. Our own experiences at Bottlerocket have shown that many of our Zope 2 apps have a limited lifetime in terms of our own ability to support them. Whether our first crop of Zope 3 applications turns out better is yet to be seen. But we've effectively (perhaps not officially) made the decision that any of our software with a real future will be rewritten anyways. A slow migration through Five does not work - *for us*. I may have been holding on to this view a bit selfishly. We still use Zope 2 and have done a variety of different things with it. But with Zope 3, we feel a lot more in control. When starting a brand new Zope 2 application, we tended to ask each other a lot of questions like - is this a small thing? can we just do it through the web? what about ZODB, should we stick everything in an RDBMS? (the answer to that led to a couple of further development options built on tools and frameworks built in house). We still have questions similar to this when starting a Zope 3 based application, but there are a lot less back and forth disucssions around well, if it grows, we're going to have to ... yeah, but we don't need that right now, let's just use ..., basically worrying about the gap between easy and direct script/template based development against moving it to product based development, versus how much harder many aspects of product based development felt for simple tasks. Not that Zope 3 is perfect in this regard. But it is a lot better. It could be better still. Which I believe is the point of #2: 2) In an alternate vision, Zope 2 evolves to Zope 5. - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. Sounds scary. But then again, I find CMF and Plone scary :). No offense against those products, but they just do far more than we need to do. - Zope 3 will explode. :) For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server. If one result of what's being discussed is that Zope the Application Server gains definition, I'll be happy. The line between Zope 3 as library and Zope 3 as Application Server feels too muddy for me today. It still *feels* like you either get all-of-zope, or you have a fair amount of work to do to get just-some-parts-of-it (he says, after losing a saturday afternoon understanding how a full Zope + ZODB instance starts up and gets all wired together, and how to use zope.publisher as a basis for anything else). I still don't fully understand what the application server side of Zope 3 really is, personally. But I would love 'Zope 3 as Library'. Zope 3 will continue as a project (or projects) for creating and refining these technologies. (It would probably make sense for this activity to to have some name other than Zope. On some level, the logical name would be Z (pronounced Zed :). An argument against Z is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts.