Dan Korostelev wrote:
> 2009/3/11 Martijn Faassen <faas...@startifact.com>:
>> If it doesn't introduce new dependencies, I think a few more definitions
>> of permissions in zope.security won't hurt (only those commonly used).
>> I'd like that better than introducing a new package. Do you think this
>> will be tolerable to you?
> I also thought about this, but I decided that people will be against
> that, because zope.security is intended to be really generic and only
> permission it defines is the special "zope.Public" (there even was
> discussions about renaming it to plain "public"). However, it's fine
> with me, as long as we define them in a separate zcml file that can be
> excluded and/or redefined for some special case.
I think in the interest of avoiding an extra package, we should move it
into zope.security right now. The main ZCML file should load an extra
ZCML file taht can be excluded. The extra load on zope.security seems to
be really light and it'll be easy to factor it out later should it be
>> We should indeed only move those widely used.
> That will require some research. When I'll be doing that, I'll post my
> opinion on what permissions should go to "standard" ones and what to
> deprecate and will call for comments and more information.
All right, thanks.
> Yup, fine then. However, I think that there's no need for a submodule
> when we can do that in simple separate zcml file. Or I miss something?
Ah, sorry, it's purely ZCML. No, I missed something, go ahead.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -