Hanno Schlichting wrote:
> repoze.zope2 and .plone have been written largely by Agendaless for
> the KARL project. That project has gone through another iteration and
> nowadays uses repoze.bfg without any Plone instead. While there are
> some individual users of the repoze.plone approach, there's currently
> no driving party behind it anymore.
Specifically, we should point out that:
- repoze.zope2 is a re-implementation of ZPublisher that is more WSGI
compatible. There are probably at least a dozen people using this
"seriously". It's clearly not mainstream, but it also has some
- repoze.plone and the zopelib package were ways to get everything to
build properly before Zope and plone were eggified. With Plone 4 / Zope
2.12, they are both completely unnecessarily. With Plone 3.2+ and Zope
2.10, repoze.plone is unnecessary, and zopelib can be emulated by
installing a regular Zope installation using plone.recipe.zope2install.
an example of this.
> Now it's perfectly possible to use most of the software with
> up-to-date versions of Zope2 and Plone, but this setup isn't
> particular well documented or explained anywhere. The entire stack is
> however production proven and there's no doubt about its quality.
The example buildout above is probably the closes thing to this being
repeatable. I've used in a couple of projects, so I know it works.
> At this point I see repoze.zope2 / .plone as a prototype for a full
> WSGI integration into Zope2. It's likely not going to see major
> adoption in its current form. It's more likely that the lessons
> learned from this project will be merged back in some form into Zope2
> itself, providing it with an OOTB WSGI story. If everything goes well,
> I hope to see Plone have official WSGI support in the future. The
> timeline for that is probably Zope 2.13 or later and Plone 5.0 with a
> final release somewhere in 2011 or 2012. With such a long timeframe
> there's obviously lots of unknowns.
This sounds right to me. Whilst there are a lot of unknowns, I don't
think the vision is contentious. It's more a matter of finding the
resources to make this happen. However, the fact that people are doing
successful things with Plone on repoze.zope2/WSGI today means that we
have a viable way to make this happen. The remaining effort is mostly
about merging things to make them easier to maintain, documentation and
testing. We may also take the opportunity to clean up a few things that
repoze.zope2 has to work around.
> In this situation it's up to every user to decide if the benefits of
> the WSGI approach outweigh the costs of going with a non-standard
> approach. As always you can make a difference by getting involved and
> driving this project forward yourself ;-)
One thing you may want to look at is plone.transformchain, which is used
by e.g. collective.xdv, plone.app.blocks and plone.caching to perform
WSGI-like transformations on the response generated by Zope/Plone. That
is actually compatible with repoze.zope2 as well (in fact, it was
working with that before it was working with stock Zope 2).
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Repoze-dev mailing list