Lennart Regebro wrote:
> This is only mildly confusing. It can also only get better with time,
> as Plone seems to continue away from Zope 2 and onto the framework,
> which means we in the future may end up with Plone, Grok and BFG being
> app servers on the Zope Framework.

The current line of thinking for Plone is about this: Plone 4 will still
run on Zope2. Plone 5 will run on Python 3.x and not depend on Zope2
anymore at all. We can all guesstimate on what kind of timeline that
will mean.

So it's highly likely that Zope 2.12 is the last release of Zope2 that
Plone is going to use. Maybe a Zope 2.13 once Python 2.7 is released
might be of interest to Plone. But otherwise I don't see any reason for
a new Zope 2 feature release anymore from the Plone perspective.

Plone is going to continue to use selected Zope libraries as everyone
else, but use Repoze or just general Python packages from all over.
Personally I want to move Plone from zope.i18n to Babel for example. We
are not bound by names or frameworks in our package choices.

> I also think all applications should move over to using repoze by
> default. BFG already does so, of course, and Plone 4 is set to do so.
> Hopefully by Zope 2.13, the old publisher can be a horrid memory, and
> repoze.Zope2 be default.

I don't know if there's going to be anyone, who is going to drive Zope2
itself forward into WSGI land. Plone is just switching to repoze.zope2
and bits of zope.pipeline by itself. The kind of radical and backwards
incompatible changes an application like Plone can do, give us much more
flexibility here, compared to the more conservative approach a framework
needs to have.


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

Reply via email to