2011 01 25 Conference Call
Bridge Info
1/25/2010 4:00 PM, US/Eastern
+1-734-615-7474 (Please use if you do not pay for Long Distance)
+1-866-411-0013 (toll free US/Canada Only)
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