Michael, Thanks, but I am not talking about an architectural change to the way roles work, just in the management of the group-member-set property.
I completely agree that roles are not the same as groups and I could pontificate at great length on the differences between roles and groups. In my opinion...a role should be a property of the user or group, like a title or descriptor and should be tied to system wide functional ability with nothing at all to do with ACLs on individual nodes, if I am an "editor" I can "edit", if I am a "reviewer" I can review, if I am a "guest" I can read. ACLs should be about who can see/access an object. If I as a guest have been granted access to an object, the guest role says I can only read, so no matter what the ACL says I should not be able to do anything but read. But that doesn't matter, all I am talking about is management of the group-member-set property of /slide/roles/[role] nodes. I would still allow manual proppatch of that property as it is now, but I would make a small modification to the code such that a mkcol [username] in the /slide/roles/[role]/ would append the [username] to the group-member-set of the [role]. Further I would remove the [username] from the group-member-set when the [username] collection is removed from /slide/roles/[role]/ This would IMHO be similar to the way the Principal property is automatically added when a mkcol [username] is executed in the /slide/users/ collection creating /slide/users/[username]/ This wouldn't change the internal use of [role].group-member-set or the implementation of roles, just the management of the group-member-set property, which is currently a tedious manual operation that is error prone. Michael Oliver CTO Matrix Intermedia Inc. 3325 N. Nellis Blvd, #1 Las Vegas, NV 89115 Phone:(702)643-7425 Fax:(520)844-1036 -----Original Message----- From: Michael Smith [mailto:[EMAIL PROTECTED] Sent: Monday, June 28, 2004 4:54 PM To: Slide Developers Mailing List Subject: Re: Roles to work more like Users? Michael Oliver wrote: > Would it be possible to change Roles to work more like Users? > > > > It would be far easier to manage if the /slide/roles/[role] could be > managed by adding a collection with the same name as the user you want > to add to that role, i.e. /slide/roles/root/root and > /slide/roles/root/Ollie would put root and Ollie in the root role, or > /slide/roles/user/john and /slide/roles/user/tom to be members of the > user role and so forth. The current method of fetching the member list > property, appending the new user and proppatch'ng it back is cumbersome > and error prone. It would be cleaner and easier to use and easier to > program with the client library if the mechanism was the same as adding > a user with mkcol to the /slide/users/ collection, yes? These are fundamentally different ideas, and trying to unify them won't work: groups and roles are NOT the same. Slide already has major problems with roles, as evidenced by the fact that role membership can be represented as a property (role membership should not be enumerable!). I agree that groups are far easier to manage than roles - and I see this as a compelling reason to, whenever possible, avoid any use of roles. Personally, I'd deprecate them entirely. Just an opinion from someone who has spent too much time fighting role/group semantic mismatches... Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
