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
-----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 tseaver@palladion.com Palladion Software "Excellence by Design" http://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-----
On 2/28/06, Tres Seaver <tseaver@palladion.com> 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/
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
participants (3)
-
Lennart Regebro -
Martijn Faassen -
Tres Seaver