Grouper Developers Forum

["blair christensen." <>]

On 2005.05.19 11:22, GW Brown, Information Systems and Computing wrote:
> 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

8 is what I am working on right now.

(1,2,3,6,7), either using the current or new group search API will
probably be worked on next as it should be relatively easy to knock off
a lot of items at once.

As for 4, 5, 12 and 13, I *would* really like to start getting more of
the privilege model in place.  I'm not sure how quickly I can do that,
however, as right now the code is generally not geared towards that at
all.  Or at least not geared to doing it in a simple, robust,
consistent and extendable manner.

Delaying 11, 9 and 10, unless I discover an absolute need for them
internally to handle some of the other items, is fine with me.

So, it looks like I agree with your ordering.  I'll update
_doc/ROADMAP_ to tentatively reflect this new ordering.

> 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.

I imagine 0.6 will just have two sources (by default), one for
groups and one for people.

> Regardless of whether we have one or more sources for people we need to 
> agree how we get a subject from an authenticated user. 
> 
> The current API has no equivalent to 'getSubjectByDisplayId'.

It doesn't but I *think* Minh was amenable to adding something like
this in.

> 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.

While there are problems with the netId == subjectId assumption, it
would certainly be a simple default to use.

> 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.

Performance is a definite problem.  Gary has pointed out a number of
areas for improvement and I'm aware of a few others.  Unfortunately,
features are still sort of winning out over performance.  Given that we
don't actually have all that many features to begin with, this isn't
surprising.

If I can ever get caught up on things I am going to start working on
some bulk loaders (and presumably provisioners) for uchicago.  Directly
working with groups and memberships on a large-scale will make it much
easier for me to start eliminating some of the worst bottlenecks.  

So, the good news is that there is lots of room for improvement.  The
bad news is that Grouper is rather slow at the moment and not a lot of
work is being done in this area - yet.