Grouper Developers Forum

[Tom Barton <>]

Grouper design call, Wednesday, 9 August 2006, 1200EDT (1600Z), 60 minutes

     +1-866-411-0013 (toll free US/Canada Only), or
     +1-800-392-6130 (alternate toll free US/Canada Only)
     +1-734-615-7474 (Non-US/CA, non-toll free, no dialout)
     http://edial.internet2.edu/call/0109331 for SIP
     PIN: 0109331 (followed by "#")

agenda:

1. administrivia
. Internet2 Intellectual Property Framework
<http://members.internet2.edu/intellectualproperty.html>
. agenda bash
. approve minutes
. review AIs

. i2mi-common

. issue tracking

. discussion to influence choice of next steps for design & development 
(below)

. else

Tom

--

Options for substantial functional enhancement to Grouper

1. Aging of groups & memberships

Provide java interface for automated removal of groups and enhancements 
for automated removal of memberships. Default implementation possibly 
uses a simple stateful deprovisioning model for groups based on 
last-manage time. Adding a TTL on memberships may be sufficient.

2. Sorting of various lists in the UI

Until now we've dodged the need to have sorted lists of subjects, 
groups, and stems in the UI. Time to settle how it'll get done.

3. History, audit

First gain clarity on the types of audit requirements to be supported, 
and whether their support should be enabled per group, per naming stem, 
or categorically. Then design the necessary internal infrastructure.

Variation: externalize via EDDY

4. Notification, changes

'Notification' is code for the infrastructure needed for event-based 
provisioning, and changes are the atomic messages to be passed along 
that infrastructure. Change support avoids the need for a downstream 
process to compute some type of logical diff in order to reflect 
incremental changes. We could elect to record changes without 
notification, but the reverse probably has little value.

5. Provisioning connectors

Although formally declared out of scope for the core product (as a 
matter of limited project resources, an anticipated great need by 
campuses, and therefore a solution to the problem of who will pay for 
them), this is still the number one thing missing from the toolkit. 
First off, a rather configurable JNDI provisioner. Any other types on a 
short list?

6. Live interfaces for query, management

Likewise declared out of scope a while back, this is probably the number 
two thing missing from the toolkit. What subset of the API ought to be 
exposed through each of what set of endpoints expressed in which web 
services idiom, and how should requests to & responses from those 
endpoints be structured?

7. Symbolic links

Things change, and so will the naming stems in a deployment and the 
authorities they reflect. Although the XML import/export tool can be 
used to do the prune and graft operations needed to convert from an old 
to a new system of naming stems, it might be good to be able to leave 
some references behind to smooth the transition.

Initial, small step: API support for moving a group to a different 
naming stem.

8. Persistent storage supporting UI personalization

The UI has "saved groups" and "saved subjects" to make certain 
management operations more efficient, or even possible. Maybe persist 
these across UI sessions.

Interconnections among these include:

* aging & history/audit: aging might encompass history, and how we age 
might make various audit requirements easier or harder.

* history/audit & notification/changes: is history a log of (or a table 
of) notifications? Are changes needed to describe the "what" that 
happened when?

* notification/changes & provisioning connectors: provisioning 
connectors will need to take up whatever slack is left in the 
notification and change infrastructure.