February 2007 - calendarserver-dev - lists.macosforge.org

static vs dynamic repository
by Cyrus Daboo 27 Feb '07

27 Feb '07

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

1 0

Re: [CalendarServer-changes] [1187] CalendarServer/trunk/twistedcaldav/directory/appleopendirectory.py
by Wilfredo Sánchez Vega 16 Feb '07

16 Feb '07

Is this code necessary? If we're ending up with multiple entries in the property, that should be fixed in the caller, not here. If this makes a performance difference, I guess OK, but it should be an exact match using ==, not a .find() call. -wsv On Feb 14, 2007, at 8:32 AM, source_changes(a)macosforge.org wrote: > Revision > 1187 > Author > cdaboo(a)apple.com > Date > 2007-02-14 08:32:03 -0800 (Wed, 14 Feb 2007) > Log Message > > Ignore %(principaluri)s in calendar user address template as server > automatically adds those. > Modified Paths > > CalendarServer/trunk/twistedcaldav/directory/appleopendirectory.py > Diff > > Modified: CalendarServer/trunk/twistedcaldav/directory/ > appleopendirectory.py (1186 => 1187) > > --- CalendarServer/trunk/twistedcaldav/directory/ > appleopendirectory.py 2007-02-14 16:16:11 UTC (rev 1186) > +++ CalendarServer/trunk/twistedcaldav/directory/ > appleopendirectory.py 2007-02-14 16:32:03 UTC (rev 1187) > @@ -304,6 +304,12 @@ > # Now do substitutions > result = set() > for template in self.cuaddrtemplates: > + > + # Ignore %(principaluri)s templates as we already > default to adding those > + if template.find("%(principaluri)s") != -1: > + continue > + > + # Loop over each host variant > for scheme, hostname, port in self.hostvariants: > for subs in subslist: > # Add in host substitution values > _______________________________________________ > calendarserver-changes mailing list > calendarserver-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/calendarserver-changes

2 5

Problem with run script on linux
by Andy Brook 15 Feb '07

15 Feb '07

I checked out the calendar server to try to get it running on Slackware version 11.0. When I went to install it, the setup section of the run script failed on trying to remove all the .pyc files for the programs it was downloading. The way it's written, it will work when there are actually files to remove, but the whole script will fail out if the files are already missing. The following patch makes this work correctly on Linux. I would think it would still work as it should on OSX, but I don't have an OSX machine to test with. Other than this, the program works great on Linux, as long as extended attributes are installed in the kernel. -Andy Brook --- run.orig 2007-02-07 13:50:35.000000000 -0500 +++ run 2007-02-07 13:50:18.000000000 -0500 @@ -216,7 +216,7 @@ echo "Removing build directory ${path}/build..." rm -rf "${path}/build"; echo "Removing pyc files from ${path}..." - find "${path}" -type f -name '*.pyc' -print0 | xargs -0 rm; + find "${path}" -type f -name '*.pyc' -print0 | xargs -0 rm -f; } www_get () {

4 5