At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote: >On 7/23/06, Phillip J. Eby ><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: >>one proxy plus one namechecker equals one capability. In other words, >>you could take the restricted interpreter, the proxy mechanism, and the >>namechecker and leave most of the rest alone, and you'd have your >>capability system. Then you could focus more time and attention on the >>parts of the problem that Zope *doesn't* solve, instead of reinventing the >>ones that it already does. > >Right, but I am trying to remove the need for a namechecker which makes it >an object-capabilities system.
As I said above: a namechecker plus a proxy *equals* an object capability. When I say "name checker" I mean the Zope type that allows you to specify a list of names that are allowed for a given object. This allowing is not based on identity or code signing or anything like that. It's just a list of attribute names: i.e. a capability mask over an existing object. When you create a proxy using this name mask, that proxy becomes a capability that allows access to the given names on the underlying object. >I like the fundemental design difference of object-capabilities It's not a difference at all, let alone a fundamental one. Zope just happens to allow other kinds of security checking *in addition to* capabilities, if you want them. However, most of its more basic encapsulation features are 100% capability based. Meanwhile, if you want to implement an object-capability system, you will need something that is basically a mask, to allow one piece of code to create capabilities that can be given to another. What you end up with for doing that is going to look almost exactly like a Zope proxy plus a Zope name checker. I hate to harp on this point, but there seems to be a trend that when people have capabilities on their mind, they tend to look at Zope and dismiss it as not being capability-based, when in fact Zope's approach is capabilities *plus* other things. (Of course, most of those "other things" have to do with closing holes like __subclasses__, while improving performance by still allowing lots of common objects not to be proxied.) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com