Groups API Questions - Protocol

Questions

1. Initial assumption is web service based with pluggable authentication
   1. Which authentication should we support?  SSL cert, ws-auth, user/pass in http basic auth, public key signature in http header, other?
2. Do we need a messaging design (xmpp)?
3. REST? (if REST, then XML, JSON, and/or XHTML)?
4. SOAP?
5. Simple calls vs Batched calls (e.g. replace all members of a group with the attached list)?  (if batched, can you pass a TX type e.g. use a transaction or not)?
6. Simple responses or complex responses (e.g. for groups a subject is in, return just the ID (KIM) or return group information(Grouper))?
7. How are results communicated back?  Result code, description, warnings, errors, success_TF, etc?
8. If you add a member to a group who is already a member, is that a success, and is there a result code that represents that? (same with delete)
9. Paging and sorting for results?
10. Is the client and server version transmitted in the request/response?
11. Should operations be idempotent?  i.e. if an operation is executed twice, should be a success both times (e.g. add member, create group)

COmanage responses

For the most part, details aren't that important to COmanage. In general, simpler is better.

1. COmanage is concerned about keeping admin tasks to a minimum (since they'll already be a lot of them), so eg user/pass is easier to manage than SSL certs.
2. Possibly, both for Gears (if backsync from the group manager is allowed) and for domesticated Apps.
3. REST is good, XML or JSON.
4. Gears isn't using SOAP, so would rather not need it.
5. Simple probably.
6. No opinion.
7. No, it's a failure.
8. Not needed.
9. Probably.
10. Isn't this basically the same as #8?

Grouper responses

Rice responses

Etc