Martijn Faassen wrote:

> Thomas Lotze wrote:
>> IMO it would be interesting to have the concept of the current site
>> available separately from the rest of with its 30
>> dependencies. (For example, zope.browserresource demonstrates how with
>> the present the need to know the current site in order to
>> determine a URL leads to a dependency on the ZODB.)
> +100 if this makes site-aware code have less dependencies. One can really
> get rid of a *lot* of dependencies this way.

That's what I thought ;o)

> We could investigate two options:
> * just removing that code that remove proxies and sees what happens to
> significant Zope 3 code bases. Risky.

To begin with, compat-tests of a number of ZTK packages and a lot of the
packages under review for the ZTK fail if I do that. This is why I said
the code is currently needed. Typically, this has to do with something
about interactions not being available to code like

> * alternatively, putting in an optional dependency on in
> zope.component. If proxy is importable, try removing the
> proxies, otherwise don't.

I thought about that one briefly, but I don't like it because it
introduces at least some knowledge about the security concept to
zope.component. While I can't follow why others consider an optional
dependency bad from a technical point of view such as usability on GAE, I
think zope.component is so low-level that we should value its conceptual
clarity greatly.


Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to