On Sun, Apr 12, 2009 at 12:31, Martin Aspeli <optilude+li...@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/collective/autopermission/permissions.py
> 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
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to