Grouper Developers Forum

["Jessica Bibbee" <>]

Grouper Working Group Meeting
July 11, 2007

 

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

Gary Brown, U. Bristol

RL 'Bob' Morgan, U. Washington

James Cramton, Brown U.

Kathryn Huxtable, unaffiliated

Shilen Patel, Duke U.

Celeste Copeland, Duke U.

Joy Veronneau, Cornell U.
Bill Kasenchar, U. Pennsylvania
Michael Gettes, Internet2

Renee Frost, Internet2

Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

 

New *Action Items*
[AI] {Gary} will send {Blair} proposed method signatures to support browsing, and {Blair} will address it for performance issues.

[AI] {Gary} will share an email with the list giving an idea of how to modify menu items based on who you are and which groups you belong to.

[AI] {Gary} will verify if there is an efficient way to default particular tasks to start in the flat view.

 

Carry-over *Action Items*

[AI] {Tom} will link in the latest javadocs for the upcoming release.

[AI] {Tom} will email [Jessica} with highlights or other notables of the new release.

[AI] {Ann and Jessica} will put together release announcement emails for the -dev, -users, and mw-announce lists.

[AI] {Blair and Jessica} will update the Archives and News pages in the wiki.

 

Future *Agenda Items*

- Roadmap updating. Step 1 - review existing docs:

    . Priorities for Functional Enhancements (Aug 2006): < https://wiki.internet2.edu/confluence/x/NBk >
    . Grouper Product Backlog (July 2007): < https://wiki.internet2.edu/confluence/x/dzs >

*Agenda*

1. v1.2.0 release
2. ldappc v1+
3. Clarifying and parsing functional and performance issues for v1.2.1
   . review indices - api
   . review connection pooling & caching - subject
   . group search - api, ui
   . sorting - subject, ui
   . xml import/export - subject, api
   . FERPA handling - * (n-tier issue?)
   . massive dependencies - api, ui, deployment & usage

*Discussion*

 

-Grouper v1.2.0

{Tom} announced that the developer team is nearing the final stages of packaging the Grouper v1.2.0 release. An announcement will be made to the mailing lists following last minute details to be wrapped up by the end of the week.

 

Given recent performance discussions, v1.2.0 will be released and any further performance enhancements will be addressed in a follow-up release. While the project generally aims for a maintenance release in the fall, a target date is yet to be established and will largely depend on the requirements list and priority of those items.

 

-LDAPPC v.1+-

{Michael} expressed concern as to the momentum of LDAPPC development. LDAPPC was developed by 2 contractors, but are no longer assigned to the project. Similarly, the Subject API is a tool that is used by both Signet and Grouper, and could also benefit from closer attention to the development cycle. {Michael and Tom} agreed that further discussion of the LDAPPC and Subject API development outside the Grouper WG context would be useful.

 

{Michael} announced that {Kathryn} will be contributing to the LDAPPC project, particularly to help address performance and functionality changes to increase scalability in a multi-CO (Collaborative Organization) environment. {Kathryn} said she will post feedback to the Signet and Grouper dev- mailing lists, continuing the topic publicly.

 

-Clarifying and parsing functional and performance issues for v1.2.1-
{Tom} expressed thanks to the Duke Developers for detailing their concerns with vivid examples. Recently, they have exposed many performance issues and have begun to seed the mailing list with various threads (c.f. subjects: Manage Groups and stem structure, both on 10-Jul.) Under the Manage Groups topic, the desire is to have a particular UI function cascading into select SQL calls against the backend. The point of discussion on the call today is not so much to resolve this issue as to decide on logical next steps.

 

{Gary} explained the current UI set-up and how that contributes to the current issue and how it might be changed to accommodate the requests. {Bob} pointed out that this represents a classic case of a UI that is expected to be rich, responsive with a friendly display, and at the same time fast. {Tom} asked whether it was a possibility to abandon the privilege interface and keep privilege checking integral. {Blair} thought it was definitely possible to simplify the existing setup, though he will need to study it more. {Gary} explained that they need to find a way to cut down the avenues that are not useful when doing the privilege checks, so as not to waste time where a group does not exist under a particular stem(s). It may be possible to put support into the API to cut out these blind alleys. The question may be whether it is wiser to spend time fixing the existing or to rip it out and integrate more tightly.

 

-Manage Groups (c.f. Shilen's email on 10-Jul)-

While TAAdmins may have many admin privileges, they would not necessarily have more memberships than others. {Gary} said there is still an issue if TAAdmins wants to view their own privileges. A possible option may be to hide Manage Tasks; should any changes be made in the UI, or elsewhere? It would save some effort if there were a slightly custom access privilege implementation with local rules in it. {Gary} said they Group had discussed enough next steps to begin shaping the work under the Manage Groups thread.

 

[AI] {Gary} will verify if there is an efficient way to default particular tasks to start in the flat view. {Shilen} said that a paginated view of groups would suffice for less than 30 groups, but it would be quite cumbersome for someone wanting to view thousands of groups. Not only would a flat view be useful, but more importantly, the performance must be satisfactory.

 

- Modify Menu Depending on User Identity-

{Celeste} asked if there was a way to control what a user may view depending on their identity. {Gary} explained that it is now possible to do so, via the wheel group. [AI] {Gary} will share an email with the list giving an idea of how to modify menu items based on who you are and which groups you belong to.

 

-Group Search-

Aside from the manage groups area, what are the implications for searching? Searching is still doing full table scans, and while it would improve privilege checking, there would still be major problems underneath. It may be possible to be more judicious about how a search is constructed. The configuration could be tuned – as opposed to the code being changed - to a different type of search that would produce a smaller selection, resulting in a shorter cycle time. For example, it may be better to search the extension, as opposed to the displayName. This can be done currently, and while it is better than searching against all of the attributes, it does not resolve the underlying issues.

 

[AI] {Gary} will send {Blair} proposed method signatures to support browsing, and {Blair} will address it for performance issues.

 

The Group agreed on the first next steps for resolving group search. They will define a review of SQL queries that the API comes up with, including indexing in the database. As for every SQL call, {Blair} said selection will be made case-by-case, and he will continue to do so. {Shilen} had reported 3 tables that they had dropped and 2 that they added. {Blair} confirmed that this was on his To-Do list.

 

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

-- 
Jessica Bibbee, Technical Analyst
Internet2

mobile: +1-734-255-6644

Innovate, participate, educate.
The  Fall 2007 Internet2 Member Meeting Call for Participation
http://events.internet2.edu/2007/fall-mm/calls.cfm