Grouper Developers Forum

[Tom Barton <>]

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.

TomZ's observation that having a non-opaque identifier helps human 
administrators fix problems has more weight to it, in my view.

> Granted I can picture some sources (e.g. web service of a remote
> federated source) where frequent retrieval of all known subjects, or
> a retrieval of all subjects, might not be convenient... hmm...

Indeed. Let's recall that one of the most successful grouper deployments 
is in caGrid.

And back to TomZ's idea vis-a-vis federation. Having a non-opaque 
identifier is often needed in order to handle security or other 
operational issues when they arise (name or email address usually). 
Maybe we can go as far as meeting that need without more substantial 
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.

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.

Tom