[CalendarServer-dev] static vs dynamic repository

[Cyrus Daboo]

Hi,
As part of the work to improve the performance of requests that operate on 
entire collections of resources, we need to improve the behavior of 
privilege determination for all child resources of a collection. Right now 
this involves getting the ACL property, adding inherited values, and 
calculating matching privileges for each resource.

One change I propose doing is to change the dead property store to use a 
database that is capable of querying all child resources in a single 
transaction, rather than the current process of reading privileges off each 
resource one at a time. In addition the goal is to remove the need to have 
the actual resource object for each child URI - i.e. the goal is to get all 
the needed data from the property store.

However, whilst it is possible to put most per-resource properties in the 
property store, certain properties are related to the resource type - e.g., 
supported-privilege-set is determined by each class derived from 
DAVResource. That property is needed as part of the privilege matching 
process.

If we stored supported-privilege-set for every resource in the property 
database, we would be able to make the "batch" privilege calculation work, 
but that has several drawbacks. First off, most resources will have exactly 
the same value for that property so storing it for all of them will 
unnecessarily "bloat" the database. Second, it makes changing the privilege 
set much harder in the future as all the entries in the entire property 
store would have to be "upgraded".

An alternative to storing the actual values for supported-privilege-set, 
would be to instead store the resource class type for each resource (e.g. a 
private property with a value "twisted.web2.dav.DAVRsource" etc). Then the 
property store can "reconstruct" properties that depend only on the 
resource class by reading that private property in at the same time as all 
the others and using it to retrieve class variables that contain the 
per-class data for supported-privilege-set.

This does solve the problem of database bloat, and partially solves the 
problem of upgrades in that the class variables can be changed in the 
future and that will affect the property values directly.

However, it does mean each resource is "statically" typed by virtue of this 
private property in the property db. This is different from the current 
"dynamic" typing where the resource class is determined by scanning down 
the URI path hierarchy from the root. We do lose some flexibility with 
this, but would gain in performance (at least that is the hope).

Comments, thoughts?


-- 
Cyrus Daboo