Subject: Grouper Developers Forum
- From: Tom Barton <>
- To: Grouper Dev <>
- Subject: Upcoming design work
- Date: Tue, 01 Aug 2006 16:17:17 -0500
Below is an annotated list of options for substantial functional enhancements to Grouper in some 1.1+ release. Let's clarify them and add or merge items to arrive at a proper expression of how we see the possibilities.
In a second, later, cycle we will identify front-runners and serialize those.
In no particular order, the potential design items are:
1. Aging of groups & memberships
Provide 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.
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.
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.
- Upcoming design work, Tom Barton, 08/01/2006
Archive powered by MHonArc 2.6.16.