Grouper Developers Forum

["Jessica Bibbee" <>]

Grouper Working Group Meeting
February 21, 2007

*Attendees*
Tom Barton, U. Chicago (chair)
Blair Christensen, U. Chicago
Gary Brown, U. Bristol
Dave Donnelly, Stanford U.
Kathryn Huxtable, U. Kansas
Brendan Bellina, USC
Ann West, EDUCAUSE/Internet2
Nate Klingenstein, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
[AI] {Tom, Blair, and Gary} will talk offline about future plans for the UI v1.2.
[AI] {Kathryn and Dave} will investigate Subject API matters, relating to the prepared statement and use of Velocity.
[AI] {Tom} will revive past threads about the Subject API.

Carry-Over *Action Items*
[AI] {Joy} will share a write-up of a Cornell use case for the provisioning connector regarding the preservation of a query for group attributes. (9-Nov-06)

[AI] {Stephen L.} will pass along a link to their CVS for a model similar to the Grouper object model, including use cases and code. (6-Sep-06)

*Agenda*
1. Near-term plans for the Grouper API & UI
2. Procedures & considerations for contributors to core components
3. Subject API v.next
4. Ldappc enhancement for provisioning Signet permissions
  . Kathryn's code

*Discussion*
{Blair and Gary} provided an update regarding the API and UI. {Blair} is working on API performance issues and many other internal changes. He needs to review the code. There is the ability to relocate stems and the code is now feature complete. The next release of the API will be listed as v1.2.

{Nate} inquired about the backwards compatibility of the upgrading process; {Tom} said you could dump the database into xml and then import into the new schema. {Blair} confirmed that a database schema is not provided, as it is generated at build and install time with Ant.

{Gary} mentioned several items on his To-Do list, including: improved stem search capabilities, improving forms to use the get method. There are also a few UI performance issues to address. {Tom} asked if there would be value in having the UI v1.2 offer stem related capabilities exposed there, or if it would be sufficient to expose with gsh. {Kathryn} was in favor of exposing in gsh, not in the UI.

{Tom} asked the Group how they wanted to balance optimum performance with the amount of work required and length of time to do so. Could the UI take responsibility for sorting stems? Where there is a limited number of stems, it might work well, though it would likely not be as functional in a flat structure, where there are many stems in one level. The Group decided that while considering the range of scenarios people will offer, the work ought to focus on the case that covers the greatest number of scenarios. {Tom} described it as modeling human networks. This will lead to a sizable amount of work for {Gary} in terms of improvements to the UI

Another suggestion from {Gary} is to build in a way to search within a list by restricting what you are looking for. After selecting and doing the search, the API would return those values. {Kathryn} mentioned she is interested in an improved method of searching groups for subject values, as it cannot be done by join queries. While {Tom} wants to avoid sorting in the API, {Kathryn} said it would add reasonable performance, and would be better to have a cached result set. She said a suboptimal approach would suffice for now, given the Group agrees that this feature is added to the API when possible, and later to the UI. [AI] {Tom, Blair, and Gary} will talk offline about future plans for the UI v1.2.

{Kathryn} raised her concern with the LDAP Provisioning Connector, in that she feels it is limited in only doing LDAP. She noted that there are no provisional tests for LDAP, only for stems; {Blair} plans to look into this matter. {Kathryn} also pointed out that the values are backwards in the assertion tests, with consequences being that any error reported will be swapped. An interesting question was whether a contributor was allowed to submit a similar level of testing to what the core offered, even if it is less than adequate. She has many ideas to offer regarding performance and functionality, which she will share with the group via the list. She is working on a version repository, which she will merge back into CVS.

The Group discussed the next release of the Subject API; {Dave} offered 2 recommendations/questions: 1) why is the source manager a singleton? and 2) the config file is hard-coded, but it ought to be parameterized. {Blair} said they plan to make the latter change.

[AI] {Kathryn and Dave} will investigate Subject API matters, relating to the prepared statement and use of Velocity. Ideas forthcoming should be sent either to the mailing list or expressed offline, as is appropriate.

[AI] {Tom} will revive past threads about the Subject API.

The next Grouper Working Group call will be on March 7, 2007 at 12pm EST.

-- 
Jessica Bibbee, Technical Analyst
Internet2

mobile: +1-734-255-6644

Think Spring!
Register for the Spring 2007 Internet2 Member Meeting.
http://events.internet2.edu/2007/spring-mm/