On Sun, Apr 12, 2009 at 12:31, Martin Aspeli <optilude+lists@gmail.com> wrote:
1) Use an event handler to ensure that any <permission /> declared in ZCML actually creates a valid, Zope 2 permission. I have working code for this here which we could put in Products.Five with ease.
http://dev.plone.org/collective/browser/collective.autopermission/trunk/coll...
Benefits: Creating new permissions becomes more predictable.
Risks: None obvious. The event handler will not override permissions that already exist.
2) Emit a warning instead of an error in Five's handler for the <class /> directive when set_attributes or set_schema are used.
Benefits: Easier to re-use existing packages
Risks: The attributes won't actually be protected. However, since Zope 2 doesn't have the concept of protecting 'set' (or security proxies) then I'm not sure there's a problem of expectation.
I like, +1.
3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly.
Benefits: Should transparently allow any invocation of the Zope 2 API to use Zope 3 permission names, allowing us to document that the dotted permission name is the canonical name everywhere.
Risks: Performance overhead of doing utility lookups. May result in name clashes, but since the permission name is a dotted name and the Zope 2 permission name isn't, I think it's extremely unlikely that this would actually happen in practice.
I'm sure we can do some performance comparisons on this one. I'd say it's worth the cost, but hard numbers would help. -- Martijn Pieters