Skip to Content.
Sympa Menu

grouper-dev - 0.6 priorities

Subject: Grouper Developers Forum

List archive

0.6 priorities


Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To:
  • Subject: 0.6 priorities
  • Date: Thu, 19 May 2005 11:22:12 +0100

I've numbered items for reference.

"initial UI release, supporting Phase 1 functionality"

1 Support for displayName and displayExtension (#270)
2 Search by the name, extension, or displayName attributes of
groups [S&B#1] (#336)
3 Search by the name, extension, or displayName attributes of
namespaces [S&B#2] (#337)
4 Implement READ privilege (#338)
5 Implement VIEW privilege (#339)
6 Search by the name, extension, or displayName attributes of groups
scoped to within a namespace subordinate to a given stem [S&B#7] (#340)
7 Search by the name, extension, or displayName attributes of
namespaces scoped to within a namespaces subordinate to a given
stem [S&B#8] (#341)
8 Improved Subject interface (#342)
9 has() (#334)
10 Improved schema validation (#267)
11 Delete groups that either have members or are members of other groups (#345)

# Grouper 0.6.x
12 Implement OPTIN privilege (#343)
13 Implement OPTOUT privilege (#344)

My priority from a UI perspective would be:

8, (1,2,3,6,7), 4,5,12,13,11,9,10

Comments in reverse order:

I'm not sure if 9 or 10 would have any impact on the UI at this stage - I think they are necessary once we support custom group types.

For 11 I have worked around this - but I need to check if I changed any Grouper code to do so.

If we don't have 12 and 13 I need to remove them from the UI for the time being.

We need to be able to search groups, but for a first release we can simplify things. I've attached what I currently have for simple and advanced searches (not actually implemented). We could decide to go with a simple search only. I currently only do a case insensitive substring search scoped by stem, and don't have any booleans. I would be happy to go with this for 0.6 and aim for more functional searching in 0.6.x when we will have custom group types to consider.

The Subject API is critical. For 0.6 it would simplify matters to have only two sources - one for people and one for groups. Having multiple sources for people would be doable so long as we don't need to search more than one at a time.

Regardless of whether we have one or more sources for people we need to agree how we get a subject from an authenticated user. In the current UI I use:
subj = Grouper.subjectType("person").getAdapter().getSubjectByDisplayId(null,remoteUser);

where remoteUser is my netId - isgwb. My subjectId is a number.

The current API has no equivalent to 'getSubjectByDisplayId'.

I don't really mind if the mapping is part of the Subject API or a separate pluggable interface - but we need a default to ship with Grouper -e.g. treat the netId as a subjectId.

public interface AuthenticatedUserIdAndSubjectIdResolver {
public String getSubjectId(String authenticatedUserId);
public String getAuthenticatedUserId(String subjectId);
}

public class DefaultAuthenticatedUserIdAndSubjectIdResolver implements AuthenticatedUserIdAndSubjectIdResolver{
public String getSubjectId(String authenticatedUserId) {
return authenticatedUserId;
}

public String getAuthenticatedUserId(String subjectId) {
return subjectId;
}
}


Finally, for now, I think we need to consider performance. I've found loading real groups with real people very slow - ~400 groups with 10000+ grouper_list values took longer that 6hrs. I need to look at this in more detail e.g. compare HSQLDB and Oracle, and look at memory usage - my loader eventually ran out of memory.

I don't think we need to solve all the performance issues for 0.6 but we need to set expectations in release notes. It would probably be useful to come up with a benchmark test we can run to create a set number (100+) of groups, memberships / privileges (1000's), including groups where the immediate memberships are groups.

Gary

----------------------
GW Brown, Information Systems and Computing

Attachment: simplesearch.png
Description: PNG image

Attachment: advsearch.png
Description: PNG image




Archive powered by MHonArc 2.6.16.

Top of Page