Jim Fulton wrote:

On Aug 24, 2006, at 7:32 AM, Christian Theune wrote:


ZODB with Blobs uses zope.proxy. Recently I discovered that due to a refactoring, the semantics of a proxy have significantly changed and a new concept of a "decorator" was born.

I don't know what you mean. The concept of decorator is not new and I'm not aware that zope.proxy was changed in any way recently to support it. The only thing that changed
was that descriptors in proxies are treated a little differently.

Well. I think we included zope.proxy on the original sprint, which is quite a while ago already, so the change might have happened in the last 18 months.

ZODB with Blobs needs the ability of a "specification decorator".

Does it really? Does anything in ZODB actually introspect interfaces?

Yes. It checks whether a storage implements IBlobStorage to find out whether to store a blob or not. One of the two storages that support blobs is a decorator (originally a proxy) that adds the blob methods two the base storage and declares that it implements IBlobStorage.

However, the zope.decorator depends also on zope.security, which in turns depends on many other things that depend on even more things. I didn't look up the final list, but as it's more than just one thing, I consider it to be too much for inclusion with ZODB.

Would it be possible to split up the modules of zope.decorator in two, so ZODB could use the specification decorator without depending on the security decorator?

On some level this makes sense. However, this package was moved up from zope.app and I think that more thought should have gone into how that was done.

This package is really small. It only defines three things: DecoratorSpecificationDescriptor, DecoratedSecurityCheckerDescriptor, and Decorator.

 Of these:

- The Decorator base class isn't used. It should be probably be removed. Unfortunately, this
   will require a deprecation cycle.

- DecoratedSecurityCheckerDescriptor is only used in one place, although it is redefined in zope.app.container. It appears that it was copied at some point and has fallen out of sync. :( I'm 99% sure that the zope.app.container should simply import this. Then it will be used in multiple places. I suggest that the definition should move to zope.security.

Sounds about right to me.

- Likewise, DecoratorSpecificationDescriptor is duplicated in zope.app.container and has fallen out of sync.

I don't remember why these descriptors were duplicated in zope.app.container. I'm pretty sure that part of the reason was that they are so trivial. I'm not enthusiastic to have an egg and a ZODB dependency for so trivial a package.

I suggest moving the DecoratorSpecificationDescriptor into zope.proxy, sich depends on zope.interface already.

Of course, this would be for 3.4.

Jup. That's the release where blobs would go into anyway.

So, the todo list for this would be:

- remove copies of descriptors from zope.app.container
- move the DecoratorSpecificationDescriptoor to zope.interface
- move the DecoratorSecuritycheckerDescriptor to zope.security
- remove decorator base class
- remove zope.decorator

Each of the named steps requires a deprecation period.

gocept gmbh & co. kg - forsterstra├če 29 - 06112 halle/saale - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to