[Cosmo-dev] CMP changes for groups in Cosmo

[Vinubalaji Gopal]

On Tue, 2007-02-06 at 12:38 -0800, Brian Moseley wrote:

> * the url for getting the members of a group should be
> /cmp/group/<groupname>/members, which explicitly relates the url of

yeh I could change that. Just had it the other way to avoid the regular
expression to match a groupname in between. 


> GET /cmp/group/testgroup/members/bcm could then issue a 302 to
> /cmp/user/bcm. PUT /cmp/group/testgroup/members/bcm would add bcm to
> testgroup, and DELETE /cmp/group/testgroup/members/bcm would remove
> bcm from testgroup.
this sounds good but I don't see a use of this in my existing UI
implementation - so I can defer this implementation or implement it if I
get better suggestions for UI.

Right now the UI is a drag n drop where the left side is a list of
users, groups (principals) in the entire system and right side is the
list of users, groups in that particular group. The admin can drag users
or groups from the left side and put it in the right side or do it the
other way. (I know the number of users, groups can become large and so
we could paginate the entire list later).


> to add multiple members to a group, we can simply POST to
> /cmp/group/<groupname>/members, and to remove multiple members, we
> DELETE from the same url, both operations with post data specifying
> the usernames and groupnames to add or remove.
keeping the list of users, groups before and after modification of data
in the client side was getting difficult for me so I thought of POST
completely destroying the list by creating a new list with the new post
data.


> * we will need an operation for getting all groups at /cmp/groups. i
> think we should be able to send a DELETE with post parameters to that
> url to delete multiple groups.
yes I have GET /cmp/groups and multiple group deletion implemented as
that wiki page says.

> 
> * we will also need to get a count of all groups - this can happen at
> /cmp/groups/count.
yes I have implemented this as well.


> hm, this doesn't seem altogether natural. what is the use case for
> doing this in one protocol operation? why not get all users, get all
> members of the group, and then have the client compute the set of
I tried doing that at first, but then its more complex than it sounds
and the implementation was not that neat. First I had to get a list of
all principals (users and groups) and then I had to do the computation
in the client side - so I thought why not just get all the non members
from the server and perform better! We could have something
like /cmp/group/<groupname>/nonmembers