You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Michael Oliver <ol...@matrix-media.com> on 2004/06/29 00:29:55 UTC
Roles to work more like Users?
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?
If the group agrees, I will do the patch and submit it. I just don't
want to do the work if nobody else thinks it is a good idea.
Michael Oliver
CTO
Matrix Intermedia Inc.
3325 N. Nellis Blvd, #1
Las Vegas, NV 89115
Phone:(702)643-7425
Fax:(520)844-1036
RE: Roles to work more like Users?
Posted by Michael Oliver <ol...@matrix-media.com>.
Daniel,
I am not talking about changing the internal workings of roles, just the
management of the group-member-set property, see my other post in reply
to Michael Smith.
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: Daniel Florey [mailto:dflorey@apache.org]
Sent: Tuesday, June 29, 2004 1:38 AM
To: Slide Developers Mailing List
Subject: Re: Roles to work more like Users?
Hi,
I'm not very familiar with the users/roles handling, but you have to
keep the following points in mind:
- The principal properties must be provided. If you add the users by
creating a collection in the role folder, you have to make the
group-member-set property a live property. As this property will not
changeable, many legacy applications, that modify this property will not
work anymore.
Have a look at:
http://www.greenbytes.de/tech/webdav/rfc3744.html#principal.properties
- The principals (users) are identified by an URI, so there can be
different users with the same name in different user-collections. So you
have to create a collection with an unique identifier. If we do so (e.g.
let slide generate the collections name by using sequences), it is not
easy to get this working.
Regards,
Daniel
Michael Oliver schrieb:
>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?
>
>
>
>If the group agrees, I will do the patch and submit it. I just don't
>want to do the work if nobody else thinks it is a good idea.
>
>
>
>Michael Oliver
>
>CTO
>
>Matrix Intermedia Inc.
>
>3325 N. Nellis Blvd, #1
>
>Las Vegas, NV 89115
>
>Phone:(702)643-7425
>
>Fax:(520)844-1036
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Roles to work more like Users?
Posted by Daniel Florey <df...@apache.org>.
Hi,
I'm not very familiar with the users/roles handling, but you have to
keep the following points in mind:
- The principal properties must be provided. If you add the users by
creating a collection in the role folder, you have to make the
group-member-set property a live property. As this property will not
changeable, many legacy applications, that modify this property will not
work anymore.
Have a look at:
http://www.greenbytes.de/tech/webdav/rfc3744.html#principal.properties
- The principals (users) are identified by an URI, so there can be
different users with the same name in different user-collections. So you
have to create a collection with an unique identifier. If we do so (e.g.
let slide generate the collections name by using sequences), it is not
easy to get this working.
Regards,
Daniel
Michael Oliver schrieb:
>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?
>
>
>
>If the group agrees, I will do the patch and submit it. I just don't
>want to do the work if nobody else thinks it is a good idea.
>
>
>
>Michael Oliver
>
>CTO
>
>Matrix Intermedia Inc.
>
>3325 N. Nellis Blvd, #1
>
>Las Vegas, NV 89115
>
>Phone:(702)643-7425
>
>Fax:(520)844-1036
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Roles to work more like Users?
Posted by Michael Smith <ms...@speedlegal.com>.
Michael Oliver wrote:
> 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 understood that (though your description here helped clarify my
thoughts). My objection is that the way group-member-set works on roles
currently is pretty broken - making it easier to use just encourages use
of that brokenness. DAV:group-member-set is a property listing the
members of a group - not a role. I'm not (for the moment, anyway)
suggesting we break the existing functionality, but I don't think we
should build anything else on top of that.
Don't consider this a veto of your proposal or anything - just my
personal comments.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
RE: Roles to work more like Users?
Posted by Michael Oliver <ol...@matrix-media.com>.
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:msmith@speedlegal.com]
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: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Roles to work more like Users?
Posted by Michael Smith <ms...@speedlegal.com>.
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: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org