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 interested stakeholders. - 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. http://svn.plone.org/svn/collective/buildout/uber/plone3.x-repoze/ shows 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 ;-) Indeed. :) 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). Martin -- 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 Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev