Grouper Developers Forum

[Jessica Bibbee <>]

MACE-Dir-Groups Conference Call

July 27, 2005

 

*Participants*

Tom Barton, U. Chicago (Chair)

Minh Nguyen, Stanford U.

Blair Christensen, U. Chicago

Brenden Bellina, USC

Ido Carmi, USC

Gary Brown, U. Bristol

Steve Olshansky, Internet2

Jessica Bibbee, Internet2 (scribe)

 

New *Action Items*

[AI] {Tom} will log a bug about the subject API to {Minh}.

 

[AI] {Minh} will initiate discussion on the {grouper-dev} list regarding packaging options for the Grouper UI.

 

[AI] {Gary} will check the Grouper UI into CVS.

 

Carry-over *Action Items*

[AI] {Blair} will send out the javadoc for proposed API changes, once it is complete. (13-Jul-05)

 

[AI] {Minh}, {Tom}, and {John} will work together to set up the UI, specifically addressing distribution. (13-Jul-05)

 

[AI] {Blair} will send signatures of the new methods to the {grouper-dev} list, which will appear in the transition between v0.5.1 and v0.6. (4-May-05)

 

*Discussion*

Discussion centered on Initial feedback from the limited testing of the Grouper UI. This feedback will provide a basis for the final changes made for the nearing release of v0.6. {Tom} suggested that the Group work to clarify several questions – what are the conventions for naming of the subject API and incorporating a source adapter, and how might they look in the future? What are the searchable attributes, and do these accurately reflect items such as the username and subject ID? What are the local practices, and which are available to this application?

 

The UI default is such you can query a string of text into the search method. It could be set up in such a way that you can override and make use of the attributes from the subjects. While this does not create limitations, it does imply that you need to create it yourself. When a search string is passed on to the source, it will be important for that source technology to understand it. The challenge lies in creating a search screen in the UI appropriate to the source. There may be a way to build a query with the source, while defining in the UI which kinds of attributes are acceptable. The end result should provide a functional system for querying, while maintaining flexibility to the application developer.

 

The query string is not sequel-like, but instead, a string of text for certain fields. The attributes are stuck to the source adapter, and are not a part of the UI.

 

The recourse file in the UI can be modified per expected attributes, and this will be explicitly stated in the implementation guide. {Tom} suggested that there be a default in the server mode, especially in the quickstart version. Feedback is needed in this area of implementation of the UI.

 

There are many JDBCSourceAdapter connections being opened in the subject API. Related problems have been worked out.

 

There are still a few components which need to be added before the v0.6 release. {Gary} will add a search command. {Blair} has made a change to the logging trees in the Grouper API, so they are not duplicated. The Group will work on making sure that the previously logged-in user is not listed after you log in. [AI] {Tom} will log a bug about the subject API to {Minh}.

 

The Group discussed various Grouper v0.6 issues that need to be addressed before the release.   All of the originally planned features have been incorporated into v0.6; {Blair} intends to add a few smaller convenience methods to the API, and he will take care of at least one known remaining bug. {Blair} said there should be a freeze on the API by the end of this week, with bug fixes and any code changes soon to follow. { Gary} will continue to work on testing of the database and changes regarding searching for groups. Full documentation is still needed for many items.

 

The Group agreed that there should be Internet2 connections, and there will be CVS administrative privileges sufficient for that. { Gary} will work out of the Bristol CVS and then will try to do an input into the Internet2 CVS. {Blair} will work with {Gary} to put the tarball into the current CVS repository. {Tom} was interested in getting a quickstart version out. [AI] { Gary} will check the Grouper UI into CVS.

 

{Gary} advocated coming up with a testing plan for checking a database, stems and groups, assigning naming privileges, etc. He encouraged anyone in the Group to work with him on coming up with a script that tests the underlying functionality. {Minh} suggested that it might be less important to have an extensive test plan for v0.6, and that bugs could be defined with every distribution. {Tom} advised documenting the testing procedure and protocol. If the quickstart distribution has structure to support comprehensive use, then it can move to v1.0 .

 

The exact packaging is still to be decided. It would be useful to have a quickstart version that one could quickly download and begin using, which offers much more than a simple screen shot. The quickstart version has a default configuration, which is an added bonus for those who are not interested in loading a database and setting up the configuration. Grouper v.0.6 would provide an opportunity to experiment, saving full functionality requirements for v1.0. [AI] {Minh} will initiate discussion on the {grouper-dev} list regarding packaging options for the Grouper UI.

 

Those experimenting with the quickstart version could place data into the database to get a feel for how it works, and they would also learn how to integrate the application with their existing infrastructure. They can put in tiles that would allow them to override the existing, should they want to, and they could do so by modifying the JSP. The Grouper API is the only item that cannot be modified, and there is justification for including it automatically.

 

The next MACE-Dir-Groups conference call will be on Wednesday, August 10, 2005 at 12pm ET.