Hi Andreas. Let me say I see the development paradigms as being the following without prejudice to any application that depends upon zope 3. Respectfully, no one is building walls. my contribution to the discussion is not about isolating folks but of the reality of the software differences.

zope 3 - an open framework - no borders, no boundaries - write and think as a python programmer. In essence zope 3 is is a framework without a frame. This fact that exists in this form gives it its elegance and power. It does not need to be an application and is more interesting when it is not.

zope 2 - an application tied strongly the cmf with the notion of a cms as the app. It is self contained and it is able to absorb zope 3 packages and technologies. I see plone as an application layer build on top of the zope 2 application.

The fact that zope 3 is not specifically an application, nor a traditional framework is also what can make it difficult for folks to distinguish zope 3 as something special. You only understand this once you are able to see it for what it is. To the uninitiated it may just seem a library of packages (and well, that's missing the point :-)) When one looks at the collection of software that makes up the python language, they see an elegant way to create. Zope 3 is like this and you are free to create anything you wish.

Folks looking for containment within a framework will look for traditional solutions that confine their development within a container with strict rules and one way to do it all. This has strong points but the least of those is flexibility and diversity. Think if our creator had thought of only one way to create an animal and the possibilities and opportunities lost to create all the diversity we see on our planet.

I've developed in zope2 and recognize and respect it as a powerful web platform that answers specific solutions. For me, considerable flexibility was lost when you are not programming as a python programmer and programming for the api of the application.

I have always wanted what zope 3 provides. I do not want to see it given any other ground or see the development of zope 3 pushed or pulled by interests that best serve one application or another. Zope 2, Plone 3, SchoolTool, Grok, Bebop, and many commercial interests and projects including those by Lovely and others are beginning to show how diverse Zope 3 can be (and all have an interest in the development of zope 3). I should say this diversity extends to desktop applications as well as the web.

Personally, I see zope 2 and 3 as distinctly different. The development is different and the goals are different. Collaboration is always a good idea but in the same way that any programmer depending upon zope 3 packages will want to maintain an interest in zope 3 development.

I also see zope 2 developers in the same context as other application developers that utilize zope3 in their efforts. Collaboration can occur freely without merging the specific development lists or interests of grok-dev, zope-dev, plone and other application development (that would have simililar interests) in the development list of zope 3.

I don't see "zope" as a synonym for zope 2 and zope 3 either, any more that I could see it as a synonym for SchoolTool and zope3 or Grok and zope 3 (though obviously all a part of the zope community with a special interest in zope 3). Common ground and unified forums for the community is a different interest than merging development lists for the software. zope 2 and zope 3 share the same name but it my opinion calling it all "zope" is really a bad idea and perpetuates a problem.

Given the way history has unfolded, i'd have rather seen zope 3 given a new name, and have had an opportunity to have dissociated itself from zope 2 in a clear way without the premise or goal of trying to fold zope 2 'the application" and zope 3 "the framework without a frame" together. It is alright (and frankly realistic) to suggest we have two software lines here that are very different. Personally, I don't see these ever being the same and future 'marketing' efforts should respect this if marketing is a concern.

The notion of the zope 3 application is fading as it should with the developments of the last year. I wouldn't want to see zope 3 revert to something or extend parts that have it looking like the zope 2 of four years ago for the sake of unifying the developer community under a generic "zope" flag. In any case, long message, but I hope this clarifies my view on this.


Andreas Jung wrote:

--On 6. Oktober 2007 12:03:06 -0300 David Pratt <[EMAIL PROTECTED]> wrote:

I agree with you Roger. I want things to stay as they are for the same
reasons. I have great respect for Zope 2 developers however there there
are two development paradigms at play that are fundamentally incompatible
despite the inclusion of component architecture in Zope 2.

What do you man by "two development paradigms"?

Please don't build a wall between Zope 2 and Zope 3 developers. Most "old-school" Zope 2 developers are doing development also with Zope 3 components and Zope 3 techniques. Look at Plone 3.0 and its heavy usage of Zope 3 techniques...impressing. The Zope 3 development paradigms are highly accepted by most Zope 2 core developers...we are all sitting in the same boat. There is a fundamental difference in the Zope 2 and Zope 3 architecture but little difference between the paradigms how we should design and write software on top of the Zope platform in the future.

The distinction between Zope 2 and Zope 3 must disappear. We must speak of "Zope". Everything else is counterproductive when it comes to promoting Zope. There is only one Zope developer community and most of us have a Zope 2 and a Zope 3 hat on (others have a CMF or a Plone head). An artificial separation between Zope 2 and Zope 3 developers is undesirable in my opinion.

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to