Grouper Users - Open Discussion List

[Kathryn Huxtable <>]

Essentially, the problem with the logical diff for isMemberOf operations is
that you're still updating the members of a group, logically, rather than
the groups for a member.

You can either choose to allocate enough memory to hold the current
membership, allowing a moderately efficient query, though not always, and
then do the logical diff among a bunch of sets, or you can use a database
table. If you use an in-memory database such as hsqldb you still have the
memory requirement. If you use a file-based database then you only need to
hold all the group names for a user at any one time. (The logical diff is
*much* faster if done in memory, but you only need the particular thing
you're differencing.)

For awhile, I've had boiler-plate code that differences two databases and
makes one like the other. I trimmed it down to a difference operation for a
table with two elements, the subject ID and the group name. This is pretty
effective.

-K


On 4/24/07 8:40 PM, "Tom Barton" 
<>
 wrote:

> Grouper indeed does not have an incremental change notification
> capability at present, though that is the next substantial area for
> development in the roadmap.
> 
> Ldappc can provision grouper groups to an ldap directory. One of its
> core capabilities is computing a "logical diff" to determine the
> incremental changes to be made in the target directory. However, its
> performance in doing so with regard to isMemberOf style of membership
> information has been found too slow in at least one large scale
> experiment. Kathryn Huxtable might comment on that, and on an idea for
> remedying that issue that arose in discussion at the signet-grouper
> combined working group meeting here at the Internet2 conference last Monday.
> 
> I'm very open to ideas on how to extend grouper or associated
> applications like Ldappc to facilitate incremental provisioning of group
> changes. Seems like it's just about time to begin those design discussions.
> 
> Tom
> 
> aragorn wrote:
>> Hi,
>> 
>> I'd like to ask, why there is now way how to get information from
>> Grouper API about deleted groups or memberships? Do you have some
>> special purpose (performance, size of database, ...) to not implement
>> this functionality?
>> 
>> We need to propagate changes (CRUD of groups and memberships) made in
>> Grouper to other systems (Sun IDM). I have idea how to "simple" solve
>> this task. Just use another DB where will be archived all groups and
>> memberships and set of classes to update this DB from Grouper. Before I
>> start to implement this I'd like to know if you plan to add this
>> functionality to future releases of core Grouper API or if we can
>> contribute this "extension"?
>> 
>> -----
>> Josef Krupicka
>> Centre for Information Technology (CIV)
>> University of West Bohemia in Pilsen
>>