[Zope-dev] Zope 4 roadmap

[Martin Aspeli]

On 17 November 2011 14:46, Laurence Rowe <l at 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:
> http://wiki.zope.org/zope2/SetParentAndNameInOFS

+1

> - Remove XML zexp export (davisagli).

+1

> - 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.

+1

> - 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
BaseResponse.

> - 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).

+1

> 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

+1

> - 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
perspective, though.

> - 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

+1

> - Move to Python 3.

+0

Martin