[Zope-dev] Zope 4 roadmap

[Laurence Rowe]

On 17 November 2011 15:23, Martin Aspeli <optilude+lists at gmail.com> wrote:
> 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?

Currently items are keyed by path in ZCatalog as they must be pulled
out with their correct acquisition context (five.intid must also
maintain a mapping based on path for the same reason.) When we have
parent pointers we will be able to use zope.intid directly instead of
five.intid (which many of us have had bad experiences with.) Using
intids will mean that renaming or moving items does not require them
to be unindexed and reindexed in the portal_catalog as they will
maintain their same intid and will open up the possibility of
intersecting result sets from a the portal_catalog with a zc.relation
catalog.

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

I expect this will only become important several years down the line,
but the more we use other people's code who have already ported to
Python 3, the less code we will have to port ourselves.

Laurence