Re: Milestone 2: authentication and authorization

Karl Fogel wrote:

> So when a branch starts having different ACLs than its ancestor line,
> some sharing is lost, but not the most important sharing (that of file
> contents). Maybe implementing ACLs as properties isn't such a bad
> idea after all, then?
>
Yes, but you wouldn't be able to /change/ and ACL on an existing
revision. You could only replace ACLs on the tip by checking in a new
revision. Oh, wow; my latest idea with ACLs in directory entries has the
same problem, except that you'd only have to duplicate the tree, not the
files. ...

The other problem is that you'd have to actually read the node's
properties before you could find out whether you're allowed to read the
node's properties, which is a bit inconsistent. :-)

So in short, ACLs have to be non-historic properties of node revisions.

Hmm. Let me think about this a bit. Got to wrap my head a bit more
tightly around the idea that our filesystem is unlike any other
filesystem I've ever seen, versionable or not.

-- 
Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/