Grouper Developers Forum

[Jessica Bibbee <>]

MACE-Dir-Groups Conference Call
February 9, 2005

*Participants*
Keith Hazelton, U. Wisconsin – Madison (stand-in chair) 
John Ballem, Brown U.
Blair Christensen, U. Chicago
Gary Brown, U. Bristol
Minh Nguyen –Stanford U.
Brenden Bellina, USC
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
*Action Items*
[AI] {John) will mail the <grouper-dev> list with a description of his
current work and experience related to using connectors with Perl.

[AI] {Blair} will rework and update the 0.6 feature prioritization
list into additional 0.5.x releases, the initial 0.6 release, and
future 0.6 releases

*Discussion*
The Group discussed the release of Grouper v0.5.1, which may be
available as soon as the end of February. This release includes fixes
for bugs found in v0.5, as well as additional internal changes. There
have been no major changes to the features offered in v0.5, but v0.5.1
is being released with the objective of offering better support for
databases. The aim is to make Grouper more stable, and everyone who
uses it will aid this effort – {everyone} is encouraged to experiment
with the latest Grouper version and pass on any bugs to {Blair} for
repair.

The greater part of the call was centered around scheduling the UI.
Once support for existing features is up, matters need to be finalized
- it may be a few weeks after that when the final v0.6 is released.
{Gary} will work on tidying up to prepare for a release documentation.
{Gary} is working on a minimal 0.6 feature set that is necessary to
support the initial UI release. It is not yet implemented yet, but the
goal is to distribute something that you can download and experiment
with. One of the next tasks will be to separate the subject interface
from Signet into a model. A future discussion topic is the local
subject table; it would be good to reach an agreement with the daily
schema. Sharing of information and developments will benefit the work
of everyone.

{Gary} discussed methods of implementation – the actual retrieval that
has been implemented so far, based on procedures. This drives related
items such as corporate websites, queries, tables that hold
information, people - subject implementation. Here we are not
dependent on the actual Grouper schema. Regarding the subject
interface, subjects will be person and group, and we need to be able
to imitate that assertion on groups. {Gary} discussed the subject type
adapter, search capabilities, and how Signet would parallel Grouper
here. There seems to be potential for more intricate types of searches
– for example, one could search against a display name, and ideally
against a stem name. Other search features are found on the list of
priorities. Other desirable, if not essential, features include being
able to delete groups, such that you can properly manage their
functionality, and also full privilege implementation. Other features
such as the ability to rename groups and work focusing on custom group
types could be included in a future release.

{Gary} discussed a demo application that would provide groups that you
could manage. Using various search/browse options, you might search
through the names - one level of the hierarchy. It would be an
acceptable 1st cut UI; not ready for production level. This would
encourage people to experiment with the system, before they actually
begin building their own groups management systems. This approach was
compared to standard demos within Signet.

The Group continued conversation on limits in terms of searching. What
happens when there are too many results? There are group memberships
and members to display. If someone writes their own adapters, it would
effectively put that level within groups. There needs to be a
configurable limit to the results. By using tools for displaying
reorder, displaying table, etc., one might be able to manage it
effectively – rather than go through the list itself. Perhaps a
subject type adapter would prove to be a more efficient means of
narrowing a large list of people.

Several features need to be completed before the Grouper 0.6 release,
including the view and read privileges. We need to look at the
significance of managing privileges outside of Grouper – for example,
how do we represent these privileges when presented to LDAP? Access
restrictions are enforced and thus limit how privileges are managed.
How do we present it in a way that the user is confident about these
limits, and can understand who can view the system, what gets
published, and the difference between these and editing controls. Are
there requirements for keeping memberships private to some groups?
Items for future agendas include ismember flexibility and listings.

A definitive release date has not yet been established for Grouper
0.6. It is expected that it will be available sometime in the next few
months, hopefully by the I2 Spring Member Meeting. It is still a
question of how tightly the UI will be coupled with v0.6. {Blair} will
look at items from the call and additional items from {Gary's} email
list. [AI] {Blair} will rework and update the 0.6 feature
prioritization list into additional 0.5.x releases, the initial 0.6
release, and future 0.6 releases.

{John} has been working on demos and feedback with adaptors and
connectors, on the LDAP side. [AI] {John) will mail the <grouper-dev>
list with a description of his current work and experience related to
using connectors with Perl.

The next MACE-Dir-Groups call will take place on Wednesday, February
23, 2005 at 12pm ET.