Grouper Developers Forum

[Chris Hyzer <>]

> How an application should integrate with "identity services" remains
> wild country these days. I'm keenly interested to see how far we can
> take the Subject API approach to meeting identification needs of
> applications like grouper. I hope we'll discover that it's not always
> necessary to replicate Subject data into app-specific DBs to get
> reasonable integration.
> 
> If we know how the Subject API should be enhanced to provide better
> support for "batch" type operations, I'd very much like to enhance it.
>

Yes, I understand this, and I wish there were a way.

Lets take my use case:

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

Without knowing the sort string, you will need to retrieve all 60k, and go to 
the subject api and get the sort string, then sort them, then get 51-100.  In 
general, doing operations across multiple sources and collating the results 
is hard without some consolidation.

If the sort string is in a table of all subjects (probably the members 
table), then this is one easy hibernate query.

Maybe we could make this optimization optional somehow (hard to think how :) 
), but I think if people want to use a UI or WS to manage large groups, that 
is not embarrassingly slow, then they will want to adopt this.

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

Thanks,
Chris