Grouper Developers Forum

[Jessica Bibbee <>]

MACE-Dir-Groups Conference Call
January 25, 2006

*Participants*
Tom Barton, U. Chicago (chair)
Brendan Bellina, USC
Joy Veronneau, U. Cornell
Steve Barrett, U. Cornell
Gary Brown, U. Bristol
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

Carry-over *Action Items*
[AI] {Bob and Tom} will write requirements for xml import/export design. (11-Jan-05)

*Discussion*
The Group discussed enhancements to group math; a new group type of "hasFactor" allows for 2 factors - compound groups and union of two groups. Memberships are calculated when you ask if a subject belongs to a group.  There may exist a few naming issues, as effective memberships are not in the database, which will have implications at run time. Each time subjects are added, a difficulty is presented in that compound groups need to be continually reevaluated. Working with LDAP dynamic groups increases slowness. As a result, there will be different performance profiles. {Brendan} commented that this is one reason why USC has stuck with static groups in the directory, so as stay abreast of which memberships have changed.

Two requirements of group math address client software, and those using the UI to manage compound groups. Efforts should be kept to a minimum, using existing methods where possible. It would be useful to be able to query a group adequately, rather than guess, though this introduces more complex code to be managed by the UI. The Group will continue to address issues of how the UI should support management of compound groups.

XML export/import is another current issue – what are the functionality requirements? – Ability to start at a namespace and export. – Relative import, being able to add where you want to, without being limited to the origin, e.g., migrating two versions of a database. There would be value to being able to switch privileges on or off for subjects. What issues are raised with forward referencing when the other group is yet to be defined?

Which memberships should be included in the XML document – immediately only, effective, or compound? The Group also discussed whether it is advantageous to have the add/modify/delete at the document or element level. Conflicts might arise between instructions in the same document. XML pertains to 2 facilities – export, and add/modify/delete.  It may be okay to do it in steps, exporting first, then adjusting as time/money permits. Cornell is waiting on further developments, to see if or how Grouper may be a web service option. Import allows you to pull XML produced by other systems, and this proves to be a useful means of tracking. Additionally, using XML, as opposed to the API directly, means being able to use a wider range of tools. A Java environment can be used for loading processes, to generate XML in the language of choice, and have it later to modify – a change log capability.

If an institution wants to maintain their own AuthZ management, but also wishes to keep it visible in Grouper, they can use the management of XML or turn it into a subject source. Using another source reduces the possibility of an update not being returned, in synch.

Grouper v1.0 supports more custom groups and fields; this allows Grouper to be a source. {Gary} noted that the usefulness of being able to delete an empty stem.

The next Grouper WG call will be held on Wednesday, February 8, 2006 at 12pm ET.