On Wed, 2009-03-11 at 15:42 +0100, Martijn Faassen wrote: > Hey, > > Dan Korostelev wrote: > > One of most large packages that really wants to be refactored but > > still wasn't touched is zope.app.security. > > In fact we did touch it a bit, moving some bits from it into > zope.security. And your zope.password work affected its dependencies of > course. But I know what you mean. :) > > > It has much in it and it > > brings many dependencies, including zope.app.form and company. And > > even some zope.* packages, like zope.securitypolicy still depend on > > it. So, let's finally refactor it :) > > > Here's a sketch of a refactoring plan I wrote after taking a quick > > look at the current package: > > > > - Move IAuthentication and other interfaces into new > > zope.authentication package. Also move there PrincipalSource and the > > "checkPrincipal" utility function. Also move there the PrincipalTerms > > class, however that will add dependency on zope.browser (which is > > really really tiny, as you may know). > > Do you expect bits of zope.app.authentication could also move to > zope.authentication or does that look implausible? > > > - Move global principal registry, its IPrincipal/IGroup > > implementations and its directives into new zope.principalregistry > > package. > > Why not name it zope.principal? > > > - Move LocalPermission into new zope.localpermission package. I > > personally didn't ever need local permissions. > > You're talking about locally defined permissions, correct, not about > giving someone a permission locally? > > > - Rewrite PermissionsVocabulary and PermissionIdsVocabulary not to > > depend on zope.app.component and move them into zope.security. It's > > generally useful there and won't introduce any new dependencies. > > > > - Move zcml definition of zope.Public permission. Maybe move security > > declaration for the `zope.security.permission.Permission` class as > > well. > > Move them where? > > > - Leave all browser views, globalmodules.zcml, _protections.zcml, > > other zope.* permission definitions in zope.app.security as well as > > backward-compatibility imports. > > > > - Just to note: the "settings" module was recently moved to > > zope.securitypolicy as there's the right place for it. > > > > Not sure about: > > > > - ILoginPassword and its basic implementations. The interface should > > probably go into zope.authentication while implementations - into > > zope.publisher. It will add a dependency on zope.authentication to > > zope.publisher, but the zope.authentication are expected to be really > > tiny and already installed for most applications, so I believe that > > it's okay. > > Why do you think the implementations of ILoginPassword should go into > zope.publisher? Why not simply into zope.authentication? > > > - PrincipalLogging - the adapter from > > zope.security.interfaces.IPrincipal to > > zope.publisher.interfaces.ILoggingInfo. I'd just move it into > > zope.publisher, because it's already tied to zope.security. > > Wouldn't zope.publisher then need to depend on zope.principalregistry > for the IPrincipal interface? > > > - ILogoutSupported flag interface/adapter. Looks like it's only ever > > used for enabling/disabling the "logout" button in the UI. I'd > > deprecate it and leave in zope.app.security. > > > > - _protections.py module. It defines a NoProxy checker for > > zope.i18nmessageid.Message and adds __name__ and __parent__ attributes > > to _available_by_default. This module was executed in > > zope.app.security.__init__ and generally does useful things for most > > of applications. The problem is that neither zope.i18nmessage, nor > > zope.location already depend on zope.security. One solution is to move > > the protections in that packages, placing the code into "try/except > > ImportError" block to avoid hard dependency. > > That last solution seems reasonable. I think Christian Theune has had > some dealings with a strategy like this during our dependency > refactoring sprint; Christian?
Sorry, I've stared at the issue for a while but can't remember that I had (something like) that during the sprint. -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
