On 17 November 2011 14:46, Laurence Rowe <l...@lrowe.co.uk> wrote:
> Here's my current understanding of the Zope 4 roadmap.
> Zope 4
> Significant progress has already been made on the following features
> and I expect they should all land in time for a Zope 4 release:
> - Storing parent pointers (elro, davisagli): we have a branch of Zope
> that changes OFS to store parent pointers on objects implementing
> ILocation 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 - Hanno continues
> working on this. See also:
> - Remove XML zexp export (davisagli).
> - 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
+0 - can we articulate the benefit of doing this?
> - 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.
> - 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.
+1, though we'll need to balance the desire to be a better WSGI
citizen with adding yet more complexity to BaseRequest and
> - 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.
+1 - I think WSGI should be the only way to deploy Zope 4.
> - Decorators for AccessControl (chaoflow).
> Future releases (Zope 5, 6, etc.)
> There has been some discussion on these topics but not much in the way
> of code yet:
> - Traversal Simplification. Remove attribute lookup from default traversal.
+1, although this will require a lot of fixes in Zope consumers. I
think we need a substantially simpler traversal mechanism that people
actually understand. I've pdb'd BaseRequest.traverse more times than I
care to remember and I still only vaguely understand it.
> - Unicode IDs in OFS
> - Remove __allow_access_to_unprotected_subobjects__=1 from OFS.SimpleItem.Item
+1, though again will break quite a lot. It's scary from a security
> - New ZMI
+0 - we certainly need better XSRF protection and accessibility and
look and feel are not great, though I think we should also consider
what we actually use the ZMI for. A low-level object browser is really
useful as a last resort admin tool. A number of the other things (like
the various CMF tools, PAS, etc) could just as well expose their own
views more independently of the ZMI, though we'd still need a way to
discover those views. Perhaps something more simliar to the Plone
control panel where tools can register views that just appear in a
list of things you may need to manage may be useful, but it'll need
some way of rooting that to e.g. Plone sites.
> - Move authentication out to WSGI middleware.
+1 - anything we can do to make AccessControl simpler and more
debuggable would be a big win.
> Long term
> - Move to WebOb as our request object. The wider Python web framework
> community seems to have settled on WebOb as their request object of
> choice, so to facilitate sharing of software components with other
> projects we should consider making WebOb our request object too
> (instead of just wrapping it). This will require buy-in from the wider
> ZTK community as the ZTK components will need
> - Move to Python 3.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -