A couple of us came together before the Plone conference to work on
various Zope related topics. We worked on the following areas:
- storing parent pointers (elro, davisagli): we have a branch of Zope
that changes OFS to store parent pointers and fixed the issues that
arose in copy/cut/paste and zexp export code. There's an issue
remaining with Acquisition, where we lost some protection against
cycle protection - I continue working on this.
- catalog using intids (rossp): we have branches of Zope, ZCatalog and
CMF which change the catalog to use intids as their internal uid and
rid. This needs more testing, but looks very promising. Currently it
uses plone.app.intid / five.intid to maintain an intid to physical
path mapping. Once the parent pointer work is stable, we can stop
doing this and load objects directly from the database connection
- Chameleon (chaoflow): Florian worked on making Zope use Chameleon by
default. This works for the most parts, but there's some problems left
in tests, as Chameleon wants an utility to be registered but a lot of
tests in Zope and CMF don't use ZCML test layers.
- Traversal simplification: Mikko worked on researching traversal and
options to simplify it. The first idea was to unify some of the code
used for URL, path and path expression traversal to bring those more
in line. Not sure how far he got ;)
- WebOb (garbas): Rok worked on bringing in WebOb as an underpinning
for the request/response objects and making both API's available at
the same time. I think the request is done and a good deal of the
response works. Doing this means we can deprecate parts of the old
request API and encourage the use of the more standard WebOb API.
- WSGI (matthewwilkes, hannosch): We fixed the bugs that had been
reported about using the current WSGI support (mod_wsgi problems,
forced dependency on repoze.who) on trunk and the 2.13 branch.
Afterwards Matthew continued on a branch to remove the ZServer/medusa
from Zope and leave only the WSGI publisher in place.
We had a bunch of other ideas on what to do, like allowing Unicode ids
in OFS, working on security and similar large topics.
I hope I haven't forgotten anyone. Most of the code currently lives in
branches or forks on https://github.com/zopefoundation. We haven't
figured out yet how to proceed with that. In terms of copyright all
committers to the GitHub repository have signed Zope contributor
agreements already, so there's no imminent legal problem.
Which of these branches should make it into Zope and for which release
is completely open and is going to be up for discussion.
On a personal note, I won't be available as the release manager for
the next Zope 4 release - as originally outlined in my mail from 2010
I'll continue to take care of the maintenance releases for the 2.12
and 2.13 series. At least unless someone else shows an interest in
picking up this work. Should there be anyone interested in this
position, speak up on this mailing list. Once someone has been found,
I'll make sure the person gets documentation and access to all
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -