Grouper Developers Forum

[Emily Eisbruch <>]

**Grouper Call 11-June-08**

**Attending**

Gary Brown, Bristol U. (stand-in chair)
Shilen Patel, Duke
Rob Carter, Duke
Bert Bee-Lindgren, Georgia Tech U.
Kathryn Huxtable, Independent
RL “Bob” Morgan, U. Washington
Dave Donnelly, Stanford
Mike Olive, Stanford
James Cramton, Brown U.
Chris Hyzer, U. Penn
Tom Zeller, U. Memphis
Ann West, Educause/Internet2
Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe)

**New Action Items**

[A1] {Chris} will add a hook veto exception field to the proposed design 
for hooks.
[A1] {Chris} will look at using ehcache for hook implementation.
[A1} {TomZ} will investigate using a relational method of representing 
changes for the audit/change log.
[A1] {Team} will move forward with JIRA items marked as “major” or 
“critical”

*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**

* Review of JIRA issues *

There was a review of open JIRA issues, and comments included:

- Discussion on the grouper-dev list is desirable prior to moving 
forward on the newly added GRP-132 (“improve the way ddl and database 
upgrades work”).

- Continued discussion with TomB on the grouper-dev list is needed on 
GRP-98 (“remove the unique id cols in many tables, in favor of keeping 
the uuid col”).

- Gary suggested that GRP-7 (“simplify UI for browsing”) be dropped and 
reopened in the future if it becomes an issue again.

[A1] {Team} will move forward with JIRA items marked as “major” or 
“critical”

* Hooks *

Chris reviewed the proof of concept on hooks for a group change and a 
membership change.
https://wiki.internet2.edu/confluence/x/zl0

Chris stated that handling membership changes would probably require 
both low-level and high-level hooks. Auditing or notifications would 
likely require a low-level hook.

Bert mentioned it would be desirable in some cases to be able to use a 
high-level hook, which provides less data to the plug-in, but then to 
include a query for additional information.

Based on discussion of the best approach and practices, it was decided:

[A1] {Chris} will add a hook veto exception field to the proposed design 
for hooks.

[A1] {Chris} will look at using ehcache for hook implementation.

Having a whole set of changes to be vetoed at once was discussed, along 
with approaches to using setters and save. Chris said he plans to 
implement high-level methods to facilitate a group of database calls.

* Audit log (change log) design *

TomZ summarized his work on the audit log.
https://wiki.internet2.edu/confluence/display/GrouperWG/Changelog+-+History+and+Notification

If changes are represented in the audit table in text that gets parsed 
or packed, then it’s hard to search. TomZ suggested evaluating a 
relational method of representing changes.

[A1} {TomZ} will investigate using a relational method of representing 
changes for the audit/change log.

There was discussion of the performance toll of using large tables. What 
are the tradeoffs of adding a record to the audit log for each change 
versus using batches or blocks? Kathryn shared experiences using 
relational tables in audit logs at KU, where records were batched when a 
query was performed, as part of the query operation.

Next call: Wed 25-June Noon EDT.


--
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/