On 22 Aug 2004 at 22:31, david nicol wrote: > On Sun, 2004-08-22 at 18:04, David R. Baird wrote: > > > > I'm not 100% sure of the Tree:: bit (although it is based on a tree > > structure), but I can't see where else it could fit in. > > > > d. > > Are the arboreal aspects important to the use of the tool or are they > implementation details? Could you change it to use a hash or a > SQL server without altering the interface? Ifyou did, would it make > said arbitrary back-end appear treelike?
I think the treeness is quite important, because groups inherit the capabilities/permissions of their subgroups. So whenever you check if your own group is permitted to do something, you know that the tree- like hierarchy of groups contained within your group is also being checked. The treeness isn't apparent when you do an authorization lookup (you just query against your own group), but it is apparent when you set up the groups. I think I was just a bit doubtful of having Tree and Group in the name at the same time, since they both describe some aspect of data structure. But they're both relevant, so I guess that's OK. If there were an Authz:: namespace, I'd probably go for Authz::Tree, so maybe I should go for Tree::Authz. By the way, I'd argue that there probably _should_ be an Authz:: namespace, just as there is an Authen:: namespace. They're different things. Although some of the Authen:: modules support authorization, it also makes sense that authorization can be abstracted out from authentication. This is more difficult than writing the damn thing! d. > > > -- > david nicol > "Someday, everything's going to be different > when I paint my masterpiece." -- Dr. David R. Baird Riverside Content Management Systems [EMAIL PROTECTED] http://www.riverside-cms.co.uk
