Improve calendar user address -> principal lookup

[wsanchez@…]

2006/06/07 10:19 AM Cyrus Daboo:

• SUMMARY

Currently mapping between a calendar user address and a principal involves iterating over the principal hierarchies looking for a match. This will not scale with large numbers of users.

[wsanchez@…]

2006/06/07 10:24 AM Cyrus Daboo: Two solutions:

1) Short-circuit the lookup if the supplied address is a relative or absolute http URI. If they are use them to see whether a principal resource exists at that location on the server and if so return that. Otherwise fallback to normal lookup.

2) Use an sqlite database to maintain cuaddress-> principal mapping for each principal collection. The DB will have to be updated anytime the <calendar-user-address-set> property on a principal is updated.

NB Some of the ACL reports could also benefit from a DB of principal properties.

2006/06/07 1:27 PM Wilfredo Sanchez: A DB index for file-based principal collections like we use in calendar collections makes some sense to me. This is pretty essential for looking up which groups a principal is a member of, for example.

Note that if the principal collection is proxying for a directory service, the service may have queries we can use. Since a directory is going to be our primary target usage, we may not need to deal with filesystem-based principals for a while.

[wsanchez@…]

This is now done via the directory service API (recordWithCalendarUserAddress).

This still does a brute-ish search by default (in the generic DirectoryService) class, but records tend to be kept in memory (as opposed to the principal search, which recquired instantiating each principal, which meant hitting the disk), so this is probably fast enough now. Subclasses can optimize this if we still need to. OpenDirectoryService could use an inverted dictionary, for example. Perhaps best to leave it as-is unless we find that it's still a bottleneck, though.

[wsanchez@…]

Milestone Preview 1 deleted

[kurt.leubner@…]

Cc Me!