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.
Regards,
David
Post by Andreas JungPost by David PrattI 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.
Andreas