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 disaster.

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 the functionality.


hilsen/regards Max M, Denmark
IT's Mad Science

Zope3-users mailing list

Reply via email to