What I'd like us to achieve going forward (ideally in Snow Leopard) with regards to our uses of groups in iCal Server. 1- It's OK for location and resource GUIDs to be members of groups. It's not exactly normal, but it's valid and OK, so let's not worry about that. So for the "enabled for calendaring" group, feel free to throw these objects into the group. 2- We need to limit our use of groups to "is X a member of Y", which is an operation we can make against DS very quickly and very frequently. We needn't cache this, on the expectation that it should be fast enough. 3- Which means we need to get rid of cases where we try to enumerate all members of a group, or the groups a principal is a member of. This one is tough due to the current delegate model. It means the DAV:group-memberships and DAV:groups should generally be deprecated. I think that's doable for principals other than the delegate sub-principals without breaking current functionality, and for delegate sub-principals, we can keep flattened lists cached. If we do this, we should be able to do all group membership checks via DS and without needing an in-memory cache. -wsv
Hi Wilfredo, --On September 8, 2008 10:52:35 AM -0700 Wilfredo Sánchez Vega <wsanchez@apple.com> wrote:
If we do this, we should be able to do all group membership checks via DS and without needing an in-memory cache.
Sounds reasonable. Some points: 1) As far as I recall DS itself does not have a "is X a member of Y" API call. Instead we have to use memberd. The PyAppleAuth module that the wiki uses has an API into memberd, though interesting they force memberd to reload its cache each time due to a purported bug. The question is whether memberd is doing anything different than what we are doing today? All we may end up doing is removing the complexity we have in favor of memberd - but then we depend on that to work properly. 2) For delegates the proper solution is to create the new "who am I a delagate for" report and cache that subset of the group memberships. That will solve the need for clients to do depth:infinity group resolutions of their own. -- Cyrus Daboo
On Sep 8, 2008, at 11:08 AM, Cyrus Daboo wrote:
1) As far as I recall DS itself does not have a "is X a member of Y" API call. Instead we have to use memberd. The PyAppleAuth module that the wiki uses has an API into memberd, though interesting they force memberd to reload its cache each time due to a purported bug. The question is whether memberd is doing anything different than what we are doing today? All we may end up doing is removing the complexity we have in favor of memberd - but then we depend on that to work properly.
The kernel does a lot of "is X in group Y" lookups. DaveO tells me this is very fast. Doug, do you know what this flushing the cache is about? -wsv
participants (2)
-
Cyrus Daboo
-
Wilfredo Sánchez Vega