Re: [Zope3-dev] Re: [Zope-dev] Two visions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro a écrit : | OK, some initial, fuzzy comments: | | On 2/27/06, Jim Fulton [EMAIL PROTECTED] wrote: |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. | | This overwhelms my complexity sensor. :-) | | I like the vision of Zope2 becoming a set of extra packages you | install for Zope3, to get backwards compatibility. Maybe this is the | same as what you call Zope 5, maybe not. I vote for this one. There's already Five product to help Zope2 products to become to be Zope3 compatible. Now, it's to Zope2 developpers to do the migration step. - -- Encolpe Degoute INGENIWEB (TM) - S.A.S 5 Euros - RC B 438 725 632 17 rue Louise Michel - 92300 Levallois Perret - France web : www.ingeniweb.com - « les Services Web Ingénieux » -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBAgEvFPzBBlIZMMRAuVXAJ9XdHxtTSYYPLUdLiKvypONfFpdwwCffDen EJjIcjNNwAZFuoSgEGV2cc4= =DmbK -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re(2): [Zope3-dev] Two visions
Ursprüngliche Nachricht am: Mon, 27 Feb 2006 21:57:46 -0500 von: Stephan Richter : [EMAIL PROTECTED] 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. Not new to Python but new to Zope (starting with Zope 3) this is my point too. Although I agree with Jim - 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. I hope that in this case there will be no additional Zope 3 penalty in a decreasing performance speed. regards Klaus ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Two visions
Lennart Regebro wrote: I like the vision of Zope2 becoming a set of extra packages you install for Zope3, to get backwards compatibility. Maybe this is the same as what you call Zope 5, maybe not. +1 -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ 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] Re: Two visions
Max M wrote: Jim Fulton wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. Zope 2 is complicated! It has too many layers of everything. The reason for Zope 3 is to make it simpler for developers. Therefore I believe that any succesfull strategy would require Zope 3 to be usable completely without all the Zope 2 layers. If Zope 3 becomes just another layer on top of Zope 2 - CMF - Plone it will not reduce complexity, as any developer would still need to learn the entire stack. Wherever practical, Zope 2 technologies should be rewritten to Zope 3 technologies to remove layers from the stack. I think these are good points. Five runs the risk of being yet another layer on a stack like Plone, but Five also gives the chance of us stripping off these layers and replacing it with something cleaner, and at the same time Five is giving an impulse to Zope 3 development as things slowly get ported to Zope 3 or written in a Zope 3 style. The Five project has the right attitude to deal with such integration issues. We have been quite successful: In Zope 2.9 it's possible to build modern Zope 3-style apps, using formlib and sqlos and so on (we've done it). In this vision, the Zope 3 project should stay where it is and push things forward. That doesn't mean Five should be ignored by Zope 3 developers, but it should be compartmentalized in people's minds. Zope 3 does innovation, Five does integration, and then the big codebases can move forward using both. 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: [Zope-dev] Re: Two visions
Philipp von Weitershausen wrote: [snip] I would vote for spelling out Zed (which would also be a little easier to google but might create trademark problems). The namespace package could either be 'z' or 'zed'. Then again, I really should take Jim's side and stay out of naming decisions. Let's please not have a naming discussion again. I think renaming Zope 3 is really bad marketing myself and naming discussions mostly a waste of time... 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: [Zope-dev] Re: Two visions
Paul Winkler wrote: On Tue, Feb 28, 2006 at 12:31:33AM +0100, Philipp von Weitershausen wrote: I will also note that just because Zope 2 won't die, it doesn't mean we shouldn't clean it up. Eventually, Zope should mostly be reusing things from Zed. +sys.maxint I think this will be the way we get a real forward migration path for an awful lot of us who are still using Zope 2 today, and expect to continue doing so. We may or may not ever port to zope 3, whatever that will mean in the future. More likely we will just incrementally improve and clean up our applications, just as Zope 2 itself will be getting incrementally better and cleaner. We'll have to address deprecation warnings at each upgrade, but at no point will we be forced to do a complete rewrite. And along the way, we'll be gradually getting access to more and more nifty features. I don't see how we need a new vision. This has been the vision (evolution, not revolution) that I've been carrying out with Five for the last few years and thanks to a lot of contributions by a large range of developers, we've been making it work. Can't we just keep going on the way we've been going then? 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
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] Re: [Zope-dev] Re: Two visions
Martijn Faassen wrote: Philipp von Weitershausen wrote: [snip] I would vote for spelling out Zed (which would also be a little easier to google but might create trademark problems). The namespace package could either be 'z' or 'zed'. Then again, I really should take Jim's side and stay out of naming decisions. Let's please not have a naming discussion again. I think renaming Zope 3 is really bad marketing myself and naming discussions mostly a waste of time... Regards, Martijn please, not Z, it is an oscar-winning film from the 70's about political corruption, military coup d'état, .. http://www.bbc.co.uk/bbcfour/cinema/features/z.shtml /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Re: Two visions
On Tuesday 28 February 2006 07:22, Martijn Faassen wrote: I don't see how we need a new vision. This has been the vision (evolution, not revolution) that I've been carrying out with Five for the last few years and thanks to a lot of contributions by a large range of developers, we've been making it work. Can't we just keep going on the way we've been going then? +1, I totally agree. 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
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
[Zope3-dev] Re: Two visions
Martijn Faassen wrote: I will also note that just because Zope 2 won't die, it doesn't mean we shouldn't clean it up. Eventually, Zope should mostly be reusing things from Zed. +sys.maxint I think this will be the way we get a real forward migration path for an awful lot of us who are still using Zope 2 today, and expect to continue doing so. We may or may not ever port to zope 3, whatever that will mean in the future. More likely we will just incrementally improve and clean up our applications, just as Zope 2 itself will be getting incrementally better and cleaner. We'll have to address deprecation warnings at each upgrade, but at no point will we be forced to do a complete rewrite. And along the way, we'll be gradually getting access to more and more nifty features. I don't see how we need a new vision. This has been the vision (evolution, not revolution) that I've been carrying out with Five for the last few years and thanks to a lot of contributions by a large range of developers, we've been making it work. Can't we just keep going on the way we've been going then? In many ways, that's precisely the idea. However, I agree with Jim when he says that we currently have a Zope 2 wanting to become like Zope 3 and a Zope 3 wanting to get all that what Zope 2 has. That'll leave us with two Zopes for a while. Zope 3 is exploding into several bits and pieces. That is good. The question is whether one of those (larger) pieces will also be an app server or whether one app server that evolves just the way we've been evolving it since Zope 2.8 is enough. I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Two visions
Stephan Richter 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. Either way we're not getting rid of the old Zope 2 code for a while. 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'm not really sure how you think we should do that... Prototyping an entire vision is a lot of work ;) 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. I really don't think you'd have to learn Zope 2 again. As I noted in my short response to Jim's proposal, a) you'll be able to continue to create web apps with just the Zed components. There won't be a zed.app or so, but zed.publisher would be the WSGI-capable publishing machinery that you can use to (given appropriate publication objects or whatever will be there in the future) publish objects using views and whatever we have not right now. b) Zope 5 will use zed functionality all over the place. Our current efforts with Five are providing a good deal of this already and we're going to continue with that. Having to learn Zope 2 all over again will probably not mean the same thing in the context of Zope 5 as it does right now. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Two visions
On Tuesday 28 February 2006 00:22, Encolpe Degoute wrote: Lennart Regebro a écrit : | OK, some initial, fuzzy comments: | | On 2/27/06, Jim Fulton [EMAIL PROTECTED] wrote: |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. | | This overwhelms my complexity sensor. :-) | | I like the vision of Zope2 becoming a set of extra packages you | install for Zope3, to get backwards compatibility. Maybe this is the | same as what you call Zope 5, maybe not. I vote for this one. There's already Five product to help Zope2 products to become to be Zope3 compatible. Now, it's to Zope2 developpers to do the migration step. +1 also, though I've done next to no pure Zope 3 development, I've done enough development with Five to realize that the major problems with developing in this manner come from having to deal with artifacts of Zope 2. As a result, I think it's best to componentize the bits of Zope 2 that provide useful features missing from Zope 3, and abandon the rest. Being able to transfer existing Zope 2 applications with little effort is not a terribly important goal IMO, especially if doing so requires making Zope 3 more monolithic and Zope 2ish. Alec ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Two visions
Philipp von Weitershausen wrote: Martijn Faassen wrote: [snip] I don't see how we need a new vision. This has been the vision (evolution, not revolution) that I've been carrying out with Five for the last few years and thanks to a lot of contributions by a large range of developers, we've been making it work. Can't we just keep going on the way we've been going then? In many ways, that's precisely the idea. However, I agree with Jim when he says that we currently have a Zope 2 wanting to become like Zope 3 and a Zope 3 wanting to get all that what Zope 2 has. I don't see how that is a however. This situation is exactly right in my opinion. That'll leave us with two Zopes for a while. Yes, having two Zopes is in my opinion completely unavoidable for the forseeable future. Zope 3 is exploding into several bits and pieces. That is good. The question is whether one of those (larger) pieces will also be an app server or whether one app server that evolves just the way we've been evolving it since Zope 2.8 is enough. I'm not sure what you mean here. I expect Zope 3 to keep the pieces it has right now, including the appserver bits. Nobody is proposing we throw away code, right? If someone has the time to replace Zope 2's appserver with what's in Zope 3, then that would be good and we'll see that happen some Zope 2 releases in the future. Calling that Zope 5 is not going to make it happen any faster. explosion, whether Zope 3 is going to be managed as a number of components or as a single story doesn't matter much for this. Presumably we'll still have Zope 3 releases that I can run, say, the documentlibrary on. For the component integrators (but that's mostly the Zope core developers) things will change. From the developer's perspective, and the deployer's perspective using Zope not that much will change - you'll still install Zope 2 or Zope 3. Perhaps the way you install it is different, but a Zope developer or deployer would typically still end up installing something that's called Zope. I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers. I don't see how else we can get there than by the route we've been taking: continuous evolution with small steps. Saying we'll have Zope 5 in the future which will include both still means we need to get there. I don't see how introducing a new name in the mix is going to help anyone, and I think in fact it will hurt. We make a commitment we'll do something, but nobody is actually signing up to actually do it in the foreseeable future. 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] Re: Two visions
--On 28. Februar 2006 16:06:55 +0100 Philipp von Weitershausen [EMAIL PROTECTED] wrote: I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers. +1 -aj pgp3JPYef1z8N.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] Re: Two visions
Philipp von Weitershausen wrote: Stephan Richter 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. Either way we're not getting rid of the old Zope 2 code for a while. Yes, the Zope 2 codebase is going to stay. It isn't going to stay for everybody in all Zope related projects, and it's already quite doable to keep Zope 2 in the background while developing new software for Zope 2, but the codebase isn't going to disappear. This doesn't mean it should be there for people who are building new applications. [snip] I really don't think you'd have to learn Zope 2 again. As I noted in my short response to Jim's proposal, a) you'll be able to continue to create web apps with just the Zed components. There won't be a zed.app or so, but zed.publisher would be the WSGI-capable publishing machinery that you can use to (given appropriate publication objects or whatever will be there in the future) publish objects using views and whatever we have not right now. b) Zope 5 will use zed functionality all over the place. Our current efforts with Five are providing a good deal of this already and we're going to continue with that. Having to learn Zope 2 all over again will probably not mean the same thing in the context of Zope 5 as it does right now. Could you please stop using a new name for Zope 3 or the zope package? You can explain this perfectly well using the existing, well established names. I'll rewrite it to demonstrate this: a) you'll be able to continue to create web apps with just the Zope 3 components. There won't be a zope.app anymore, but zope.publisher would be the WSGI-capable publishing machinery that you can use to (given appropriate publication objects or whatever will be there in the future) publish objects using views and whatever we have not right now. This is a proposal for the evolution of Zope 3. Zope 3 is already going in this direction. b) Zope 2 will use Zope 3 functionality all over the place. Our current efforts with Five are providing a good deal of this already and we're going to continue with that. Having to learn Zope 2 all over again will probably not mean the same thing in the context of Zope 2 + Five as it does right now. This is what we are actually doing with Zope 2 right now, starting with Five on top of Zope 2.7, and continued further with Zope 2.8, Zope 2.9 and presumably Zope 2.10 and beyond. It's nothing new, and it will take more effort and time to get further. Renaming this to Zed or Zope 5 is not going to make anyone's life simpler or easier, nor will it make any development go faster than it does now. Instead we're going to confuse everybody with completely uncalled for name changes. 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] Re: Two visions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Max M wrote: Jim Fulton wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. Zope 2 is complicated! It has too many layers of everything. The reason for Zope 3 is to make it simpler for developers. Therefore I believe that any succesfull strategy would require Zope 3 to be usable completely without all the Zope 2 layers. If Zope 3 becomes just another layer on top of Zope 2 - CMF - Plone it will not reduce complexity, as any developer would still need to learn the entire stack. Wherever practical, Zope 2 technologies should be rewritten to Zope 3 technologies to remove layers from the stack. I think these are good points. Five runs the risk of being yet another layer on a stack like Plone, but Five also gives the chance of us stripping off these layers and replacing it with something cleaner, and at the same time Five is giving an impulse to Zope 3 development as things slowly get ported to Zope 3 or written in a Zope 3 style. The Five project has the right attitude to deal with such integration issues. We have been quite successful: In Zope 2.9 it's possible to build modern Zope 3-style apps, using formlib and sqlos and so on (we've done it). In this vision, the Zope 3 project should stay where it is and push things forward. That doesn't mean Five should be ignored by Zope 3 developers, but it should be compartmentalized in people's minds. Zope 3 does innovation, Five does integration, and then the big codebases can move forward using both. I think the other major point is the door #2 proposal takes pressure off of Zope3: under that regime, Zope3 does not need to grow all the features present in Zope2, which door #1 *does* imply. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEBHBA+gerLs4ltQ4RAs22AJ44rNQIZB9HCt1S6fp7s36Hq68MNgCgv37w PHiyspa7XahkllCJmueEU5w= =ZyJQ -END PGP SIGNATURE- ___ 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] Re: Two visions
On 2/28/06, Tres Seaver [EMAIL PROTECTED] wrote: I think the other major point is the door #2 proposal takes pressure off of Zope3: under that regime, Zope3 does not need to grow all the features present in Zope2, which door #1 *does* imply. I still would like to know wich these missing features are. Unless it's TTW development, which, as mentioned, I think should be viewed as a separate set of packages. Most Zope3 developers do not want or need it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.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] Re: [Zope-dev] Two visions
Jim Fulton wrote: [snip] I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both. I think we already have Zope 5, and it's called Zope 2.9. Perhaps I'm wrong. If so, how does Zope 5 differ from Zope 2.9? Regards, Martijn ___ 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] Re: Two visions
Tres Seaver wrote: [snip] In this vision, the Zope 3 project should stay where it is and push things forward. That doesn't mean Five should be ignored by Zope 3 developers, but it should be compartmentalized in people's minds. Zope 3 does innovation, Five does integration, and then the big codebases can move forward using both. I think the other major point is the door #2 proposal takes pressure off of Zope3: under that regime, Zope3 does not need to grow all the features present in Zope2, which door #1 *does* imply. What I'm confused about is that we've already solidly gone through door #2 a while ago. Since we went through door #1 once people started developing pure Zope 3 applications, I don't see the either-or of these visions. Sure, there is pressure on Zope 3 for features that aren't there yet. Overall I think that's good. The pressure shouldn't be artificial and just a point by point comparison with Zope 2, but if actual projects need a feature in Zope 3 they can start building it and that's only good. What is new here? What is the concrete proposal besides juggling around names confusing everybody? 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: [Zope-dev] Two visions
Martijn Faassen wrote: I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both. I think we already have Zope 5, and it's called Zope 2.9. I'd rather say it's called Zope 2.15 or something :). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Two visions
On 2/28/06, Jim Fulton [EMAIL PROTECTED] wrote: Zope 2 is more mature than Zope 3 in a lot of areas. WebDAV and process management are a couple of examples that occur to me off the top of my head. Ah, and here I got an answer to the question I just posted. :) Much of Zope2 maturity is there in a thorougly non-reusable way. We won't get WebDAV support for Zope3 objects by including some old crufty Zope2 code. This means that for most of these features, we will have to build something new anyway. This overwhelms my complexity sensor. :-) Sorry, I'm not sure why. Not the text, the result. :) Zope2 + Zope3 + Five is a MASSIVE complexity, and I think it is important that we don't make things more complex than necessary. I think the best vision for the Zope future is to have: 1. A set of basic non-webby techniques. This is ZODB, zope.interfaces, zope.components and all that. 2. An object publisher, that publishes the ZODB objects built with the techniques in point 1, including user handling, security, traversal, yadayadaydad. This would be known as Zope3. 3. An extension to Zope3 that includes the shim to support two modules called Products, all the old default products, and the support to make the Zope3 publisher publish these type of objects. In other words, a Zope2 backwards compatibility product. The steps to get here involves stuff like replacing Zope2s security with Zope3 security, replacing Zope2s publisher with Zope3s publisher, and so on, until Zope2 is almost nothing more than a set of products. 4. Other extension sets for Zope3, like z3ecm, for making ecm systems, and z3ttw for through-the-web development. Now, there may be something that is obviously unfeasable with all this. But it sure is much less overwhelmingly complex than some sort of Zope5. I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both. Doesn't that mean we only keep Zope3? ;-) And given some of the discussion over the last month or two, I think this is pretty important. Yup. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.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] Re: [Zope-dev] Two visions
On Tue, 2006-02-28 at 17:29 +0100, Martijn Faassen wrote: Jim Fulton wrote: [snip] I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both. I think we already have Zope 5, and it's called Zope 2.9. Perhaps I'm wrong. If so, how does Zope 5 differ from Zope 2.9? Are you kidding? Zope 5 will be backward compatible with Zope 2 and Zope 3. It will allow configurations that look a lot like Zope 3. It will have the best of both systems, and improvements to both. It is where we put all of out app-server efforts. Among other things, it will have Zope 3's publisher and security model. It will provide support for non-developers much the way Zope 2 does now, but with better solutions that ZClasses. And, it will allow us to cleanly separate the efforts on an application server, from out work on widely usable components. 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] 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
[Zope3-dev] Re: [Zope-dev] Two visions
Philipp von Weitershausen wrote: Martijn Faassen wrote: I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both. I think we already have Zope 5, and it's called Zope 2.9. I'd rather say it's called Zope 2.15 or something :). Seriously, we are developing applications that use huge chunks of Zope 3 technology and are portable to Zope 3 in a short time right now, on Zope 2.9. Zope 2.10 and further will make it all even better of course, but let's not forget what we already have right now. It's 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
Re: [Zope3-dev] Re: [Zope-dev] Two visions
Jim Fulton wrote: On Tue, 2006-02-28 at 17:29 +0100, Martijn Faassen wrote: Jim Fulton wrote: [snip] I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both. I think we already have Zope 5, and it's called Zope 2.9. Perhaps I'm wrong. If so, how does Zope 5 differ from Zope 2.9? Are you kidding? No, I'm not kidding. Zope 2.9 is the closest thing to Zope 5 that we have today, that people can work with. Zope 2.10 will hopefully be closer too, and so on. Zope 5 will be backward compatible with Zope 2 and Zope 3. It will allow configurations that look a lot like Zope 3. Sounds like the original vision of Zope 3 without the X. I thought we never got around to developing this stuff the last time. What changed? It will have the best of both systems, and improvements to both. Zope 2.9 has a lot of two systems. It doesn't have improvements to both, as we see that's clearly the mandate of the Zope 3 project, not of the Zope 2 or Five projects. We improve Zope 2 by taking bits of Zope 3. Mixing these things up into a Zope 5 puddle risks mixing it all up a lot. It is where we put all of out app-server efforts. Among other things, it will have Zope 3's publisher and security model. It will provide support for non-developers much the way Zope 2 does now, but with better solutions that ZClasses. And, it will allow us to cleanly separate the efforts on an application server, from out work on widely usable components. When do you think all this work will be finished? Who will work on it? What do we do in the mean time? What do we tell people? Do you really feel comfortable promising all that? How are we not on the course to reaching this featureset, eventually, anyway? I don't see how *saying* what Zope 5 will contain will make it *exist* any time sooner. These sound like useful evolution proposals for Zope 2 and Zope 3 to me... The current story of Zope 2, Five and Zope 3 gets us in the right direction (Zope 5, if you want to call it that, though I would definitely want to introduce yet another name in the mix), step by step. We don't promise too much to people. We don't raise the wrong expecations anymore. Everyone in the community is on board. We are already doing the work that's required to reach the ideal of Zope 5. You could rename Zope 2.10 to Zope 5.0, but I don't see what good that would do except to confuse people. It won't contain the features you list unless someone actually does all that work. The alternative is to put Zope 5 in the nebulous future when all the work you list is done, and it'll be just like our mythical Zope 3 without the X then - confusing people and raising the wrong expectations. 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] Re: [Zope-dev] Two visions
On Feb 28, 2006, at 12:33 PM, Martijn Faassen wrote: Jim Fulton wrote: Are you kidding? No, I'm not kidding. +1 to what Martijn said in this email (not quoting the whole thing to save precious bandwith). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Notice: zope.interface is now a separate project
Am 28.02.2006 um 17:28 schrieb Paul Winkler: On Mon, Feb 27, 2006 at 09:24:49PM -0500, Stephan Richter wrote: On Monday 27 February 2006 16:56, Paul Winkler wrote: At pycon we have just moved zope.interface into a separate project (in preparation for eggification). It's now a separate project at http://svn.zope.org/zope.interface/trunk/ and is stitched into zope as an external. I would really like to see a proposal for this. We need to stop using sprints as excuses for not following the process we decided to use. Haven't we said forever that we want parts of zope 3 to be easily usable independently of each other? Is there anything controversial about making that more convenient? I have the feeling, that these questions are not exactly the right answer to the concerns Stephan had raised. I'm honestly sure that the work you are doing is good and that we all benefit from this, but proposals are also about communication. And communication is also important, especially in these times, where there is an ongoing discussion about the future of zope development goals. People who are using just the interfaces of z3 need to adapt to the reorganisation. I think twisted are using them. I'm surely in no position to judge about the technical implications, but the eggification process, for which this work is a preparation surely is a candidate for a proposal. With regards, __Janko ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Notice: zope.interface is now a separate project
On Mon, 2006-02-27 at 21:24 -0500, Stephan Richter wrote: On Monday 27 February 2006 16:56, Paul Winkler wrote: At pycon we have just moved zope.interface into a separate project (in preparation for eggification). It's now a separate project at http://svn.zope.org/zope.interface/trunk/ and is stitched into zope as an external. I would really like to see a proposal for this. We need to stop using sprints as excuses for not following the process we decided to use. I understand your sentiment. This is a really minor change. Really just a repository rearrangement that doesn't affect python code. I don't think a proposal is really needed for this. We aren't going to move any others for now. We're doing the eggsploration on a branch and will certainly provide a proposal before doing anything permanent. 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] Notice: zope.interface is now a separate project
On Tuesday 28 February 2006 11:28, Paul Winkler wrote: Haven't we said forever that we want parts of zope 3 to be easily usable independently of each other? Is there anything controversial about making that more convenient? My post is not about the merit of the change, but about neglecting the process that *we all* decided to use. I was against always requiring proposals, other voted for it. Now that we have it we have to use it. Sprints have a tendency to hastily make decisions; I certainly did my part as well. Sprints should be either used to brainstorm and write proposals or implement existing ones. We cannot just neglect our own process, otherwise its worth nothing. 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] Re: Two visions
On Tue, 28 Feb 2006 17:33:05 -, Martijn Faassen [EMAIL PROTECTED] wrote: I don't see how *saying* what Zope 5 will contain will make it *exist* any time sooner. These sound like useful evolution proposals for Zope 2 and Zope 3 to me... The current story of Zope 2, Five and Zope 3 gets us in the right direction (Zope 5, if you want to call it that, though I would definitely want to introduce yet another name in the mix), step by step. We don't promise too much to people. We don't raise the wrong expecations anymore. Everyone in the community is on board. We are already doing the work that's required to reach the ideal of Zope 5. You could rename Zope 2.10 to Zope 5.0, but I don't see what good that would do except to confuse people. It won't contain the features you list unless someone actually does all that work. The alternative is to put Zope 5 in the nebulous future when all the work you list is done, and it'll be just like our mythical Zope 3 without the X then - confusing people and raising the wrong expectations. Martijn, I think you make a very sobering point. It's important to be a little careful with what you promise, and to keep a clear story for the more peripheral community and to outsiders. Zope 3 has, it seems, always been driven by a desire to make the perfect framework. In many ways, that's good, and the result to date is very beautiful. It's important to keep some ties to the real world, the applications people deploy on, systems like CPS and Plone and Silva, and not tempt them to too many false starts or with false promises that leaves them waiting forever. A vision is good. Commitment to that vision is even better. Just be careful what you promise. :) Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Two visions
On Tue, 28 Feb 2006 16:41:08 +0100 Martijn Faassen [EMAIL PROTECTED] wrote: Could you please stop using a new name for Zope 3 or the zope package? You can explain this perfectly well using the existing, well established names. I strongly disagree with this sentiment. To me the name change for Zope 3 seems essential. I'm not strongly inclined as to whether Z or Zed or ? is a good choice for the name, but I think the google search argument suggests it should be spelled out rather than an initial. Also, if you want it pronounced zed, you'd better spell it out for us Americans who will otherwise call it zee. This is a proposal for the evolution of Zope 3. Zope 3 is already going in this direction. True. This is what we are actually doing with Zope 2 right now, starting with Five on top of Zope 2.7, and continued further with Zope 2.8, Zope 2.9 and presumably Zope 2.10 and beyond. It's nothing new, and it will take more effort and time to get further. True. Renaming this to Zed or Zope 5 is not going to make anyone's life simpler or easier, False, IMO. nor will it make any development go faster than it does now. Instead we're going to confuse everybody with completely uncalled for name changes. The problem is that Zope 3 is already very confusing. To anyone who is not among the Zope cognoscenti, the project is simply called Zope (though nobody knows what the it is!). It then has two versions 2 =Stable and 3=Development. That's okay now, because it's more or less true. However, if you want Zope3 and Zope2 to co-exist, the names are a serious problem (from a marketing perspective), because to the people who matter -- potential new adopters -- there is tension between two different perceptions, neither of which is good: 1) The Zope project is hung as the result of a rewrite gone bad -- the Zope 3 project is eternally in development mode, leaving Zope 2 as a currently viable, but essentially orphaned project. Run from the sinking ship! 2) Zope2 is dead, Zope3 is the new Zope. But it is hard to learn and only for serious Python programmers. Zope is just a serious system-designers' package -- scripters should go try one of the other frameworks. Not for me! Yes I know that neither of these perceptions is true. But you will be engaged in a constant pitched battle against them if you stick with the existing nomenclature. If you instead call Zope2 Zope5 then you will defeat these interpretations, but shadow the Zope3 project (the old version). No matter how you spin it, the numbers imply either age or importance. You must lose the numbers, unless you really mean them to represent versions. (As cute as the name Five is, I hate Zope 5. If you want to hang on to that idea, then instead rename Zope2 to Five (isn't it quickly becoming synonymous with that package?) and let Zope3 become Zope). Mind you, this suggests renamin Zope Corporation to Five Corporation and/or starting a whole new marketing campaign around a new name (yuck). I personally like the Zed name (but spell it out!), because it backforms well -- ZOPE = Zed Object Publishing Environment so the Z finally stands for something. Or so you can pretend, anyway. Meanwhile, Zed would be a toolkit for Python web application development. Hmm. zed.com is some kind of British TV site. zed.org is a dead link, but is apparently regitered. As for the name change confusing anyone -- it won't, because it's not a name change, it's a fork (or a refactoring if you like). The only people affected by this confusion are the developers themselves and the tightly-knit core of Zope3 developers -- all people who you can count on to figure it out no matter how confusing it is. The ones you can't afford to confuse are the new adopters, and they will find the present situation more confusing, IMHO. Of course, I'm just a user of Zope, not a core developer, but perhaps this makes me more aware of the market I'm talking about. I certainly do encounter some confusion when I try to explain the Zope situation to other people. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Two visions
Martijn Faassen 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. I don't think we disagree here. Like you, Martijn, I believe in evolution. I find the idea of Zope 3 not having to catch up with Zope 2 very appealing. We can continue to evolve Zope 2 instead. And yes, Gary, this means we will eventually get rid of or provide alternatives to crufty Zope 2 APIs. Zope 2.9 has already deprecated one particular Zope 2 API (the event stuff), I expect upcoming versions to do more like that. 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. You're absolutely right. So focusing the effort in the app server development department seems only logical. I just don't understand how the current zed/Zope 5 proposals would make everything go faster or be easier or be clearer... It just articulates in papal words what has been going on so far and what might be the future for Zope 3 vs. Zope 2. Leaving aside Jim's naming suggestion, door #2 is a clear vision for the continuation of Zope 2 and Zope 3 in a common platform. It is nothing that is done today or tomorrow. There no immediate speed ups in development, only long-term ones, hopefully. I spend a fair amount of time on Five development just to reproduce Zope 3 features in Zope 2. On the other hand, a lot of people spend a fair amount of time on bringing Zope 2 features to Zope 3. Why couldn't these efforts be consolidated? Will the consolidation product (Zope 5) be backward compatible with Zope 2.9 as we have it now? Probably not, there's an evolution path to it. Will we be able to evolve to it? I certainly think so. Perhaps it has been misunderstood, but Jim's door #2 proposal doesn't really make any technical claims nor promises, it is just a vision to focus efforts in certain things. It's an effort roadmap. And it is actually very close to the lines of thinking that let you, Martijn, (and eventually myelf) start or embrace the Five project. I see it as the logical Zope roadmap resulting from the Five efforts. In a way we should be happy that the Five effort showed that Zope 2 is still important but is also willing to evolve. By the way, I think Terry Hancock made some very good points regarding marketing issues. However, as a core developer, I would tend my vision is blurred on this particular issue :). Philipp ___ 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
