[Zope-dev] Re: Proposal: Merge philikon-aq branch into Zope trunk

Tres Seaver tseaver at palladion.com
Thu Apr 17 13:05:23 EDT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hanno Schlichting wrote:
> Hi.
> 
> I'd like to propose to merge the philikon-aq branch into Zope trunk aka 
> Zope 2.12.
> 
> Scope:
> 
> For those unfamiliar with the branch, it makes Acquisition aware of 
> __parent__ pointers. This makes it unnecessary to use Acquisition 
> mixin's for Zope 3 code to use them in Zope 2 code. The security 
> machinery of Zope 2 will still be able to work as expected.
> 
> Status:
> 
> All tests in the Zope itself pass. New tests have been written for all 
> edge cases found during the development of the branch.
> 
> As a real world exposure Plone has been used to test the branch. All 
> tests in Plone except one edge-case of a monkey-patch loaded package 
> still pass. Plone in current versions make heavy use of Zope 3 and Five 
> technologies inside Zope 2, so I see this as a very good indicator for 
> the readiness of the branch. The one edge-case is something which needs 
> to be fixed in Plone, as it doesn't make use of any official API.
> 
> Risks:
> 
> Using Zope 3 code inside Zope 2 has lead to various 'inventive 
> solutions' to work around problems. Some of these have not used official 
> API's. It is possible that some of those might need to be adjusted. 
> Adjusting them should be straight forward in most cases and mostly 
> consist of removing the hackish workarounds.
> 
> The second problem that might arise, is that the implicit assumption 
> that every object inside Zope 2 inherits from Acquisition base classes 
> no longer holds. Code that relies on the various aq_* attributes to be 
> there need to be adjusted to use the Acquisition methods instead.

The major downside here is that restricted code doesn't have access to
the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and
hence use the attributes.  ('aq_base' should not be allowewd at all, as
it strips away security context).

There are probably thousands (or even tens of thousands) of templates
and scripts "in the wild" which use these attributes.  I don't think we
can break them in a single release:  we need to deprecate them first
(with suitalbe logging output), and maybe even provide
'__parent__'-aware workarounds / fallbacks in their implementations.

> This 
> change is trivial to do and doesn't need to be done at first. It only 
> needs to be done when you want to allow direct Zope 3 code in your 
> application. As part of the branch all code in Zope 2 itself have been 
> adjusted to use the aq_* methods.

Good!

> Timeline:
> 
> I would like to do the merge as soon as possible, so people can easily 
> test it against all their applications and report back problems.
> 
> Merging it into Zope trunk will get it into the Zope 2.12 release which 
> is at this point not scheduled yet, but is unlikely to get a release 
> before early 2009. This should give us plenty of time to test.
> 
> Opinions, votes?
> 
> Hanno
> 
> P.S. Thanks to philiKON for doing most of the work on this branch :)

Many kudos to both of you.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIB4NT+gerLs4ltQ4RAvFlAKDLXkUC/ffrP4pGfNFC94Q815GcQgCfXqFU
WqXqkO8p6JAZiOT4zpgg4wQ=
=iWAn
-----END PGP SIGNATURE-----



More information about the Zope-Dev mailing list