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: > 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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )