[Cosmo-dev] CMP changes for groups in Cosmo

[Brian Moseley]

On 2/6/07, Vinubalaji Gopal <vinu at osafoundation.org> wrote:

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

use the regular expression, it's fine. we're already doing that for other urls.

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

tho it's not necessary for your ui, it is necessary for completeness
to serve other clients. even if you don't implement certain features
now, you should put placeholders in the documentation for them.

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

sounds good.

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

the problem is that it invalidates the created and modified timestamps
of member relationships (assuming you have them).

it might be better for your ui to send a remote add/delete membership
command every time a name is moved from the left box to the right or
vice versa. this would keep both the client code and the protocol
specification simpler.

> yes I have GET /cmp/groups and multiple group deletion implemented as
> that wiki page says.

the wiki page says POST /cmp/group/delete, which is what i'm
responding to. tacking /delete onto the end of the url is a bad
practice. the url is meant to identify a resource, not an operation -
the http method defines the operation.

re-reading rfc 2616, it seems to me that DELETE with parameters is a
bad idea also. probably the best thing to do is to POST to
/cmp/group/<groupname>/members and include a parameter that tells the
server to delete rather than create.

> 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

yea that is preferable to the url you had before.