Re: [Zope3-dev] Re: Two visions
Terry Hancock wrote: 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. I agree that it'd have been better for us, in retrospect, if Zope 3 were not called Zope at all, but something else. I also agree that if we change any name, changing the name of Zope 3 to something else is probably the least damaging and has potential gains, such as dropping the commitment that Zope 3 will do what Zope 2 can, and so on. It also has the potential gain that non-Zope people will be more likely to adopt the use of Zope 3 code. Whether the gain outweighs the damage done I'm not so sure of. I recommend any message change that requires requires significant future development activity to make true. So, a proposal that says we need have a version of Zope that can run both Zope 2 and Zope 3 is fine, but I don't want to change the name of Zope 2 now based on the assumption that this will happen 2 years from now. It won't happen soon and, though I don't assume and hope this, it might never happen. 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: Two visions
Stefane Fermigier wrote: Strange how (most of) the Plone people seem to be so quick in willing to sacrifice the Zope brand :( It's not about sacrificing the Zope-the-app-server brand. It's actually about growing it in the sense that it becomes much clearer WHAT THE HELL Zope actually is. Or can you explain what Zope is in one sentence? I surely can't. I currently need more than a page in my book. Rocky Burt is right, the naming actually confuses the heck out of people. In that sense, Zope X3 was not such a bad idea that it clearly said that Zope 3 is totally different. Just the 'X' itself standing for 'eXperimental' was bad Zope3-marketing in itself, so we dropped it. I will also note that Jim's proposal is really not a lot about naming (he wants to stay out of it) but about focusing effort in ONE application server and ONE set of reusable libraries. This focus in efforts seems to suggest to come up differnet names for the two things, but that doesn't mean they can't still be related in a brand naming sense (e.g. Zope and zopelib or somethign like that). 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: Two visions
On 3/1/06, Terry Hancock [EMAIL PROTECTED] wrote: The problem is that Zope 3 is already very confusing. That may be, but it doesnät help, because the name is Zope3. If you rename it, then you will only add to the confusion, becuase then there will be Zope2, Zope3 and Z, and everybody will be even more confused. Since the difference between Zope3 and Zope3 is becoming less with every release, we would then in the end have three different names for the same thing. Trust me, that won't help a bit. Jims proposal of Z(ed) was also for something different, namely the set of technologies that Zope 3 build on, as I understand it. That makes some sense, as Z + Object Publishing = Z Object Publishing Environment = Zope. But I'm not sure it will be helpful, and following this debate we can see that even that additional naming is confusing. So, stop flogging a dead horse. No renaming. Not now anyway. -- 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: Two visions
On Tuesday 28 February 2006 22:56, Terry Hancock wrote: 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. What are you talking about? Zope 3 is very stable and it is used in production on several sites. 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
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: 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
[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: [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
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
[Zope3-dev] Re: Two visions
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. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ 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
Max M said the following on 2006-02-27 17:26: 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. read the full sentence that Jim wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. ... 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. In this scenario I cannot see how much of the old ways of zope2 remain (unless I have a totally unrealistic view of what Jim proposes). zope 2 or zop3 become an issue of configuring which components/parts to use. /dario -- -- --- 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] 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. Layers are good, when they reliably hide complexity. The reason for Zope 3 is to make it simpler for developers. Yep. 14'30'' wikis and such. 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. You mean, on top - below ? (And Plone - CPS ;) ). Wherever practical, Zope 2 technologies should be rewritten to Zope 3 technologies to remove layers from the stack. To make discussion concrete, is there a list of (core, not CMF) Zope 2 technologies that are currently missing from Zope 3 ? S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ 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
Dario Lopez-Kästen wrote: Max M said the following on 2006-02-27 17:26: 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. read the full sentence that Jim wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. ... 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. In this scenario I cannot see how much of the old ways of zope2 remain (unless I have a totally unrealistic view of what Jim proposes). zope 2 or zop3 become an issue of configuring which components/parts to use. But he also says: - Zope 3 doesn't have to reproduce all Zope 2 features. Which i fear could mean that the Zope 2 stack will hang in there for ever. I am pretty shure that is not what he meant meant to imply, I just wanted to make my view clear. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ 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
Jim Fulton wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. +1 as already discussed at PyCON. - 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. ;) 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. 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. I'll note that while Zope will remain to be the application server (in its Zope 5 incarnation), you should and would still be able to create WSGI-capable object-publishing applications with the Zed pieces fairly easily, for example when you don't need the full-blown Zope experience. 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. A Zope distribution would include a fair number of Zed eggs and the Zope-specific things should live under the 'Zope2' namespace package. Fortunately we're already starting with cleaning up some of the top-level packages (zLOG, TAL, StructuredText) in Zope 2.10. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
