Grouper Developers Forum

[Chris Hyzer <>]

> -----Original Message-----
> From: Tom Barton 
> [mailto:]
> Sent: Friday, February 27, 2009 12:17 PM
> To: Grouper Dev
> Subject: Re: [grouper-dev] subject attribute cache?
> 
> Chris Hyzer wrote:
> > - Get members 51-100 of a group of 60k members sorted by name without
> > retrieving all 60k members and without looking up 60k members from
> > the subject API.
> 
> Is there a more compelling use case than paging through a 60k list 50
> at
> a time? I'd rather solve that problem by not leading the user there.


This is a basic use case.  I think a Grouper UI should be able to show the 
users in a group in alphabetical order.  For 60k users in a group, we need 
paging.  We should be able to go from page to page.

Here is a more advanced one.  I want to search for all the users with "John" 
somewhere in their subject description in a group of 60k members.  To do that 
right now, I would need to get all members, and search the subject API for 
that subject based on each subjectId.  Then I also might want to sort and 
page the results.

Is that a better example?

> replication. But we'll also need to be able to operate in environments
> where that info just isn't available, that all you have is a SubjectId.

Agreed.  And in those envs, using the UI might be slow or unusable, as it is 
now (at least for me :) ).

> 
> Subject API pulls. Should we consider adding another, optional,
> interface between grouper and site IdM that pushes changes to
> subscribed
> Subject info? Useful more for dynamic groups, but could also
> potentially
> grow into a standard way to manage replicated Subject data. Maybe
> "Subject Maintenance API" or something.

Sure, that would do it also, and would also lead to the solution the problem 
of quick subject searches across multiple source and paging and sorting.  
Users need to be able to search for subjects quickly, and in sort order to be 
able to use a Grouper UI...

Thanks,
Chris