Grouper Developers Forum

["Jessica Bibbee" <>]

Grouper Working Group Meeting
August 8, 2007

 

*Attendees*
Tom Barton, U. Chicago (chair)
Blair Christensen, U. Chicago

Gary Brown, U. Bristol

Dave Donnelly, Stanford U.

Shilen Patel, Duke U.

Clara Jelinkova, Duke U.

Celeste Copeland, Duke U.

Michael Gettes, Internet2

Jessica Bibbee, Internet2 (scribe)

 

New *Action Items*

[AI] {Shilen} will repeat profiling and other diagnostics to gauge progress on GRP-6.

[AI] {Klara} will ask power-users at Duke for feedback on their searching requirements.

[AI] {Shilen} will contribute to the JNDI and/or JDBC development work.

[AI] {Tom} will request that {Shilen} be added to the list of CVS committers.

[AI] {Tom} will share a write-up of his vision of a large-scale item that addresses integration of the I2MI-Common software and where it fits into the roadmap.

 

*Agenda*

1. Status of work to address performance issues.
2. How should group search defaults and workflow be arranged in the UI?
3. New CVS committers?
4. Solicit input on priorities for substantial functional enhancements

*Discussion*

 

-Status of work to address performance issues-

(c.f. < https://wiki.internet2.edu/confluence/x/Zz4 >)
{Blair} has looked into batching of SQL, which is trackable in JIRA. He has begun other work including subject caching, which he expects to finish up early next week. Additional subject items will follow. One item in the queue is to tweak LDAPPC for Grouper query.

 

[AI] {Shilen} will repeat profiling and other diagnostics to gauge progress on GRP-6. He asked {Blair} if GRP-6 would resolved caching issues when querying memberships in a group, but {Blair} said it likely would not address that issue, though he was unsure about the affect on the sorting component. The subject caching should involve caching of subject attributes; those attributes that have been retrieved will be cached. With that fixed, {Gary} said sorting should also improve, as caching would reduce the number of queries. In terms of SQL batching, {Shilen} said that in addition to the email he has already sent, he will try to identify other areas that could be improved upon.

 

The Group still has not confirmed whether or not performance issues of the JNDISourceAdapter necessitate further work, and if so, just who will do so. {Michael} said that in the meantime, it would suffice to provide a caching mechanism that would address JNDI issues. He asked which controls would be exposed for caching. {Blair} said that GH cache is used for subject caching, where there is a config file that can be adjusted. {Klara} was encouraged by the amount of exploratory work in progress and noted that backing the queries will produce significant improvement. Likewise, Duke's contribution is providing the necessary feedback to further this area of Grouper's development work.

 

-How should group search defaults and workflow be arranged in the UI?-

The Group aimed to address the main issue with group search, being that a default group [substring] search leads to full table scans without a way around. The first step may be to address missing workflow, though the way searches are performed in the API is not effective, due to its structure. While the latter is marked in JIRA, it has not yet been resolved. There is a limit on how well a query across groups can perform; improvements on the handling of scoped searches are needed.

 

{Michael} suggested identifying which databases support substring searches and making a decision to not support those which do not support substring searches. {Gary} suggested that it may not be an issue with Hibernate; Oracle supports Oracle text, which allow more free text in a search. {Blair} mentioned that Hibernate has a way of supporting integration with a search engine. Currently, Grouper is not using the most recent version of Hibernate, though updating this will help with other performance concerns.

 

{Tom} said it would be helpful to know more about which kinds of searches people were interested in doing. What level of full-range technologies are needed? What exactly is a user looking for when looking for a group, e.g., name, browsing in a stem space, in this stem or below this stem? {Tom} hopes that determining the contexts of group searching will yield optimization. The next step involves real people with real, not hypothetical, scenarios. [AI] {Klara} will ask power-users at Duke for feedback on their searching requirements.

 

-Next Release-

The Group decided that LDAPPC might be able t o make use of the group search work once it becomes available in the next release.  A pre-release tarball will be available for users to investigate the included fixes and report back on whether they are substantial enough for a release.

 

{Klara} reported that Duke is targeting deployment for 6 months later. In November, they will be reviewing the newest version of Grouper and how applications would take advantage of Grouper; the update would happen in mid-December and continue through winter break. Grouper is likely to produce two maintenance releases; the Group agreed that a target date of November 1 should afford adequate timing. Duke's primary push is for improvements in searching and end-user experience via the UI, in addition to the performance issues raised. While the performance fixes are easier to put into place, any changes to the UI will need to provide adequate time for retraining.

 

iTunes U. is a main driver for Duke's anticipated summer 2008 deployment. Testing and gathering feedback will require that they have access to the UI by February. It will first be reviewed by the internal IT staff, followed by other departmental IT staff. Their feedback can then be reincorporated into the general release.

 

-New CVS committers?-

{Tom} reminded the Group that Grouper development is open to new CVS committers. All items should be passed to the Working Group for review and approval, including the new idea and also its final work, before committing to CVS. {Shilen} will probably have more substantial items to contribute as the profiling and gathering of data continues. [AI] {Shilen} will contribute to the JNDI and/or JDBC development work. [AI] {Tom} will request that {Shilen} be added to the list of CVS committers.

-Prioritization 4. Solicit input on priorities for substantial functional enhancements-

(c.f. < https://wiki.internet2.edu/confluence/x/NBk > for the priorities as of one year ago)

{Tom} shared an existing roadmap in the wiki, which the Group plans to reincorporate into. He mentioned a few people in Stockholm who are working on a hooks structure; they sent a demo framework using AspectJ. Eventually, this work on change notification and auditing will be shared on the <grouper-dev> mailing list.

 

{Michael} suggested that Grouper and Signet ought to use parallel, if not identical, subject mapping mechanisms. This will lead to better integration capabilities. [AI] {Tom} will share a write-up of his vision of a large-scale item that addresses integration of the I2MI-Common software and where it fits into the roadmap.

 

The next Grouper Working Group call will be held on Wednesday, August 22, 2007 at 12pm EDT.

-- 
Jessica Bibbee, Technical Analyst
Internet2

mobile: +1-734-255-6644

The best relationships are built on trust:
We have a lot InCommon.
http://www.incommonfederation.org