Martin Aspeli wrote: > Chris McDonough wrote: > >> Creating parallel "adapter", "utility" and "subscriber" handlers is really >> how I >> should have started things out, but I didn't, and given that there are people >> using the system in the wild that this would cause problems for in a new >> release, I wanted to ask for comments. > > This seems like a fairly silly way to make repoze.bfg more of an island > than it already is. What is the real-world cost of those dependencies? I > know there are a few problems - running on GAE, detailed security > audits, that kind of thing - but I'm not convinced it's an issue for > most people. > Why can't we instead try to work with the Zope 3 project to untangle the > dependencies there? It's definitely a desirable goal in that project > too, but one that hasn't happened for lack of the type of analysis > you've done here.
Note that the reasons aren't only to get rid of dependencies for the sake of getting rid of them. And note that the dependency graph is not as fucked as it might appear, given the requirements of the existing directives. There are more practical reasons to create a different set of core directive handlers, and there are reasons the dependency graph is the way it is now, which I should have mentioned: - Zope wants the concept of "trusted" adapters and utilities. From the docstring of the "trusted" attribute of IAdapterDirective: "Trusted adapters have unfettered access to the objects they adapt. If asked to adapt security-proxied objects, then, rather than getting an unproxied adapter of security-proxied objects, you get a security-proxied adapter of unproxied objects". If this doscstring description alone isn't enough to make you want to rip that particular code out, please consider that BFG has no concept of "untrusted" code. If folks use the "trusted" flag on an adapter declaration in ZCML within BFG, I have absolutely no clue what will happen. Its usage would be a bug in a BFG app. Note that this feature requires "zope.security". - Zope wants to gate access to adapters, utilities and subscriptions based on a permission. The concept of permission it uses has no bearing on bfg applications; utility usage is never security-protected in bfg apps. Like "trusted", the usage of the "permission" attribute on an adapter or utility declaration in BFG would be a bug. Note that this feature requires "zope.security". - The "interface" directive mutates the global CA registry directly. BFG apps don't use the global registry; they keep a CA registry per-app. The usage of the global registry in a BFG app would be a bug. In summary, the directives that Zope uses to make adapter, utility, interface and subscriber registrations are far down the road of 1) encouraging the use of "untrusted" code, 2) gating access to utility and adapter lookups based on a concept of permission that only Zope itself has and 3) depending on the global registry. All of these things are either not useful for bfg or actively harmful. Maybe there's some potential to create a set of core ZCML registration handlers for utility, adapter, subscriber, and interace that are not actually part of BFG, but on which BFG and other non-Zope apps could depend. I suspect this is the only realistic way to go forward: I don't think it's reasonable to tell the people who have Zope apps in production which use these declarations that they won't be able to use untrusted code or permission declarations, or the global registry. - C _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
