[Zope-dev] Re: [Zope3-dev] Re: Two visions?
On Fri, 2006-03-03 at 09:30 +0100, Max M wrote: Benji York wrote: If we want people outside of the zope community to use these components, they should not have the word zope anywhere in their name. If it says zope people will *always* assume it is for use only with/inside Zope (Zope 2 more often than not). Would we want people outside the community to do this? We want as much as the python developer as possible to use pieces of zope. This means those pieces of zope will have had greater testing, more reviewing, and ultimately, more people contributing. At this point, I think the number of people that already use zope3 components and have never used zope the application server would be larger than expected. For those who don't get put off by names right away, zope3 CA is a nice piece of work. - Rocky -- Rocky Burt AdaptiveWave - Consulting, Training, and Content Management as a Service http://www.adaptivewave.com Content Management Made Simple ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Two visions?
Rocky Burt wrote: On Fri, 2006-03-03 at 09:30 +0100, Max M wrote: Benji York wrote: If we want people outside of the zope community to use these components, they should not have the word zope anywhere in their name. If it says zope people will *always* assume it is for use only with/inside Zope (Zope 2 more often than not). Would we want people outside the community to do this? We want as much as the python developer as possible to use pieces of zope. This means those pieces of zope will have had greater testing, more reviewing, and ultimately, more people contributing. I am *not* against other developers using bits of Zope. So I am sort of being the devils advocate here. But everytime it is mentioned, it is allways mentioned as a purely good thing. But it is in fact not without cost. Eg. conflicting interrests of 'external' and 'internal' users, or code that becomes more complex because of different use cases. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Two visions?
Benji York wrote: Philipp von Weitershausen wrote: Good point. There's the question: Does this zed thing need a different name at all? If we want other people to pick it up, then it seems like a good idea to distinguish it from Zope-the-app-server. Paul seems to suggest that in his response. How about zopelib? If we want people outside of the zope community to use these components, they should not have the word zope anywhere in their name. If it says zope people will *always* assume it is for use only with/inside Zope (Zope 2 more often than not). Would we want people outside the community to do this? Would it ever be an audience bigger than 5-10 developers somewhere who would even have different goals than the Zope community. It is difficult enough right now to herd this flock of cats called Zope developers. Why would we want to make it even more difficult by adding other communities? Personally I could not care less if Page Templates are used in TurboGears and other frameworks. Splitting up software into chunks with few dependencies should be done because it is good software practice. Not to favour other communities. We should rather make a cool stack that will include people in Zope. Please remember It is *still* the sexiest technology out there! -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] 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 pgpe9Th17c7O9.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] 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- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
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/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] 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! ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
