...
0167481# (Participant Code)
Attendees
- Jen B
- Keith H
- Chris H
- Scott C
- Benn O
Agenda
- Group API Data Structures and Operations and Client-Provider Interface Considerations
- API Phase 1 Deliverables and next steps
- Integration with frameworks? (eg: Spring)
Notes
...
- Query API vs Management API? (ie: read/write groups vs read/write permissions)
- Who needs a management API? COmanage, Atlassian, Oracle, uPortal
- Common group permissions: Admin the group (add/remove members), public (self-subscribe), readable (eg by a portal but not by the public)
- Groups of non-Persons and Groups?
- uPortal portlet administration is through groups
- Role Based Accounts, Services, Portlets, Agents, Hardware Devices (switches, etc)
- Probably better not to try to enumerate all possible attributes
- Though it might make sense to borrow from existing schemas
- Do we have too many group identifiers?
- Scott: single unique ID for all use cases, probably a URI with some segment holding a serial number to make it unique
- Alternate: URN+Display Name (URN could equal systemlocalprefix+systemname)
- URN or URI? URI -> URL for REST
- "Renaming Problem": political entity is renamed, or VIP wants the existing name
- Can this be handled by a "MOVED" reply? (In the latter case, if you want the new group with the old name, you have to explicitly ask for it.)
Action Items
New
...
- Chris: Find out why subject type was dropped from I2 subject API
- Benn: To put together new identifier proposal
- Benn: Clean up Group API Data Structures and Operations for wider distribution
- All: Identify use cases for renaming