Grouper Developers Forum

[Emily Eisbruch <>]

**Grouper Call 28-May-08**

**Attending**

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.

**Discussion**

* Issues with Grouper 1.3.0 *

The “HashMap” issue will become a JIRA item to be fixed for Grouper 
1.3.1 (see 
https://mail.internet2.edu/wws/arc/grouper-users/2008-05/msg00041.html).
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

(see https://mail.internet2.edu/wws/arc/grouper-dev/2008-05/msg00056.html)

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
Internet2

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

Internet2 Workshops
Hands-on. Brains-on.
http://www.internet2.edu/workshops/