Skip to Content.
Sympa Menu

grouper-dev - Draft Minutes: Grouper-Dev call 28-May-2008

Subject: Grouper Developers Forum

List archive

Draft Minutes: Grouper-Dev call 28-May-2008

Chronological Thread 
  • From: Emily Eisbruch <>
  • To:
  • Subject: Draft Minutes: Grouper-Dev call 28-May-2008
  • Date: Fri, 30 May 2008 13:11:03 -0400

**Grouper Call 28-May-08**


Tom Barton, U. Chicago (chair)
Gary Brown, Bristol U. (UK)
Caleb Racey, Newcastle U. (UK)
Dave Donnelly, Stanford
Chris Hyzer, U. Penn
RL "Bob" Morgan, U. Washington
James Cramton, Brown U.
Steve Barrett, Cornell U.
Joy Veronneau, Cornell U.
Josh Drummond, UC-Irvine
Neil Matatall, UC-Irvine
Tom Zeller, U. Memphis
Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe)

**New Action Items**

[A1] (Chris) will experiment with high-level methods of implementing hooks, and then he will report back to the group with an email including a proof of concept coding example.

*Carryover Action Items*

[AI] (All interested) Review the Grouper and I2MI-Common roadmaps (links below), and discuss on the list, with a particular focus on whether the loader should be included in Grouper 1.4.


* Issues with Grouper 1.3.0 *

The “HashMap” issue will become a JIRA item to be fixed for Grouper 1.3.1 (see
There was a UI issue of navigation in a certain way causing the current location of the group being worked on to got lost. This has already been fixed in CVS, and the fix will be in Grouper 1.3.1.

* Continued discussion on hooks and notifications *

Tom reviewed the decisions made so far:

- Reliable messaging has been deferred.

- There is a need for pre-hooks, but questions remain about functional capabilities.

- There is a need for notification, but divergence about how to go about it.

Tom raised the question of whether it is reasonable to efficiently implement notification by first doing audit history.

There was discussion of the transaction boundaries in Grouper: when a commit happens and when it is possible to veto a transaction or a group of transactions. Tom noted that in some contexts the current transaction boundaries are not appropriate. What is the best way to let the developer control transactions as a basis for hooks?

Chris proposed adding to the API a high-level method of implementing hooks. This approach would involve fewer hook calls and fewer update statements, but the same number of commits.

[A1] (Chris) will experiment with high-level methods of implementing hooks, and then he will report back to the group with an email including a proof of concept coding example.

There was discussion of suggestions in Chris’s email of 22-May-08


The group agreed:

- Multiple event registration (multiple plug-ins per hook) will be deferred.

- The API will be allowed to put code in hooks/notifications, even though
they are not registered.

- There will be one place to register hook code pre- or post-operation,
and it can be transactional or not or a mixture.

Chris suggested using codes for hook classes.
Gary stated he prefers an approach where there is an interface for every hook, and the developer decides whether to combine into classes. Gary agreed to look at the proof of concept that Chris will develop on this issue.

Next call: Wed 11-June Noon EDT.
Gary will chair the meeting in Tom’s absence.

Emily Eisbruch, Technology Transfer Analyst

office: +1-734-352-4996 | mobile: +1-734-604-5562

Internet2 Workshops
Hands-on. Brains-on.

  • Draft Minutes: Grouper-Dev call 28-May-2008, Emily Eisbruch, 05/30/2008

Archive powered by MHonArc 2.6.16.

Top of Page