Jeff Shell wrote:
I think this keeps Zope 3 as we know it alive, keeps the Zope brand
intact, and offers a future for Zope 2 and similar caliber desires for
a Big App Server while not interfering with the more "pure" and simple
concepts that makes Zope 3 appealing for developers like me.
I think its an absolutely terrible idea!
The most succesfull Zope 2 "product" out there is most likely Plone. And
it has everything and the kitchen sink in it.
Python also has a lot of libraries included, which means that you
seldomly need 3. party libraries to extend Plone.
I fear that loosely coupled libraries does not make an app server. I can
just imagine the upgrade hell when one package requires two different
packages, and another package requires the same two different packages,
but in different versions.
Canonical releases of compatible package collections is a *must*.
Splitting it all up in small chunks that are out of sync would be a
Releases that contains a *huge* compatible collection of packages is the
most effective way to move forward in an unified way.
Plone products works together because Plone is so well defined.
Sometimes this feels like a straightjacket. On the othe hand, in plain
Zope 2 it is practically impossible to reuse other peoples products on
your own site because the playing field was too loosely defined.
But just like you don't have to learn every Python library to use
Python, you should not have to know every package in the app server.
That is not a question of making seperate releases though, it's the age
old programming problem of structuring code with few interdependencies.
So throw everything into the release. heck even throw Zope 2 in there if
you have to. But dont force the programmers to use it before they need
hilsen/regards Max M, Denmark
IT's Mad Science
Zope3-users mailing list