On Tue, 2001-11-20 at 23:11, Tavis Rudd wrote:
> > That's not what I was hoping for: that still means there has to be
> > a group editor_of_book1, editor_of_book2, etc., while I'd like
> > "editor" to be a role that is specific for a certain object (book1,
> > book2, etc).
[...]
> Ok, I see what you're getting at now. In that case, a 'role' is a
> set of permissions to perform certain actions on an resource. Users
> and groups that are given the 'role' editor for a resource are
> allowed to edit but not delete it. By allowing a group to belong to
> other groups you get this behaviour. What you're suggesting would
> internally be implemented like this anyway ('editor_of_book1'). The
> question then, is whether the implementation details should be hidden
> from the user.
I suppose roles (or whatever -- I don't have a word for quite what I was
thinking about) could be implemented as groups. You could have an
editor group, to which editor_for_book1 would belong. But I don't want
to have an editor_for_book1 group at all. I guess what bothers me about
that is that book1 is local to some context -- the books section or
whatever -- but editor_for_book1 is global. If every local permission
issue has to be resolved with changes to the global permission system
(i.e., by adding a group), then it discourages sufficiently granular or
accurate localized permissions.
> > I think there needs to be more opportunities for abstraction in the
> > permission system. Also, a more declarative model might be easier
> > to manage.
>
> More declarative in what sense??
Well, the process to deal with ACLs is usually procedural -- when
something happens, you (or your script) go in and manipulate the ACLs
just so, to represent whatever happened. A more declarative way would
have permissions be more rule-based (where rules might rely on data
structures). So when you wanted to express an abstract change of
permissions -- like, uh... designers should be able to edit any .tmpl
files -- you would add a rule that would say just that, as opposed to
doing a chmod like operation.
When you can express intentions, I think the result is much more
manageable. OTOH, it's easier for people to understand concrete
operations...
> > > > I don't think ownership is a necessary metaphor, though
> > > > sometimes it is a useful metaphor. Sometimes it is
> > > > meaningless.
> > >
> > > I agree that in most cases the concept of ownership will be
> > > meaningless, but some of the AppIdeas on the Webware Wiki would
> > > need this concept. So it's best to build it into the base
> > > system.
> >
> > I don't think things should be built in because they might be
> > needed -- instead we should build a structure where they can be
> > implemented as needed. I don't want everything to have an owner
> > just because a few things need ownership, just like everything
> > shouldn't have an executable bit, etc.
>
> I just mean for the hooks to be built-in. That would not require
> that everything have an owner.
In the more general sense, you might want to have relations. A person
can "own" something, perhaps another person is the "creator", or
"manager", etc. I suppose that's what you were thinking of as
roles...? Ownership could just be another role.
Okay, I think we've got three ideas of roles just in this one email.
Damn terminology.
> > > Correct me if I'm wrong, but it seems that UserKit can't be used
> > > with non-servlet files.
> >
> > As far as I can tell UserKit has absolutely no web-based or
> > webkit-based assumptions. It is totally seperated. It also
> > doesn't address anything to do with permissions, just users. It's
> > quite minimal.
>
> Ok, then so the only way to use UserKit to manage permissions for
> non-servlet files would be to call it from the Application class like
> I was suggesting.
I suppose -- but I don't really see how Application is necessary. You
can always just import the module and use it directly. Isn't that good
enough? I don't see what Application gives you that plain modules don't
-- they are both similarly global.
Ian
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
