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