James, Sure, the client library or command line client could add a number of user and role related helper methods and I think that is a good idea, but I think the command line client needs to be thoroughly revamped to improve its stability and dependability before it needs to be expanded.
I don't think it any less standards compliant to manage the group-member-set property in synch with children of that node any more or less than the change that added a Principal element to the user metadata when a mkcol of the user is done in the /slide/users/ collection. Nesting of roles however may indeed preclude my idea and I will look into that unless someone on this list knows already and can chime in. 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: James Mason [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 29, 2004 8:32 AM To: [EMAIL PROTECTED] Subject: RE: Roles to work more like Users? Would a convenience method in the webdav client be enough? Something like addUserToRole(userHref, roleHref) that automatically parsed the group-member-set property and made the necessary modifications. The drawback to this is that it would only work when using the Slide client (versus another client). It should be more compliant with standards, though. There's a note in Domain.xml about nested role depth. I don't know if that refers to something like /slide/roles/role1/role1.1 or if it's about roles being listed in a group-member-set property, though. If it's the former that could inhibit creating users as child collections. I do think there needs to be an easier way to do this, though. And automatically cleaning out role references when a user is deleted is a great idea I think. -James >>> [EMAIL PROTECTED] 6/29/2004 7:31:05 AM >>> 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] --------------------------------------------------------------------- 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]
