[Cosmo-dev] CMP changes for groups in Cosmo

[Brian Moseley]

On 2/1/07, Vinubalaji Gopal <vinu at osafoundation.org> wrote:
> Hi all,
>    I finally managed to document the changes to CMP for adding group
> support. Most of the management actions are similar to user management,
> except for adding, viewing membership information.
> http://wiki.osafoundation.org/Journal/CmpGroups

nice work. here are a few comments:

* the url for getting the members of a group should be
/cmp/group/<groupname>/members, which explicitly relates the url of
the members resource to the url of the related group. this url should
be included in the xml for a group resource.

* for each member listed in the members resource, how about providing
a link to a corresponding member resource? for example:

<members xmlns="http://osafoundation.org/cosmo/CMP">
 <user>
    <username>bcm</username>
    <url>http://localhost:8080/cosmo/cmp/group/testgroup/members/bcm</url>
  </user>
  <group>
    <groupname>group1</groupname>
    <url>http://localhost:8080/cosmo/cmp/group/testgroup/members/group1</url>
  </group>
</members>

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.

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.

this all more RESTfully allows a client to operate on a member
resource rather than having to make assumptions about how to construct
the member resource's url, and it provides a natural mechanism for
individual membership operations without overloading the operations on
the group resource itself.

it also implies that usernames and groupnames are all part of the same
unique set of identifiers. i think that makes a lot of sense.

* 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.

* we will also need to get a count of all groups - this can happen at
/cmp/groups/count.

> I will also need to get a list of members that are not in a particular
> group. Thinking of adding something like:

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
non-members?