Hi Wilfredo, --On March 9, 2007 9:50:46 AM -0800 Wilfredo Sánchez Vega <wsanchez@wsanchez.net> wrote:
It's true that resources looked up via the "fast path" in the directory hierarchy are not cached, but I don't know why this is broken.
Only resources looked up through the request are cached, and anyone calling urlForResource() has to be aware of that. So don't call urlForResource() on a resource you obtained by other means. In the case of principal resources, call principalURL(). It has always worked this way.
Except that some "core" functions need to use urlForResource and there is no way of knowing where those are. The problem I ran into was the principal-match report did the fast lookup of the principals, but then needed to return properties on those. One of the property lookup behaviors is to check quota values and that requires getting the parent for the current resource which means doing the urlForResource, parentForURL etc thing. That broke because there was no urlForResource entry for the fast lookup. The problem is how should I know that I have a fast looked up resource? All I did was ask for the group-membership set from a principal. BTW this was in Twisted code no caldav code, and Twisted certainly has no idea about fast lookup. That is why I think it is better if urlForResource is a method on the DAVResource class, and the resource then figures out whether to query the request or return a value it has cached (the fast case). We can then override that for our "fast" resources, whilst the default is to use the request. In fact urlForResource is used a lot as part of finding the parent resource. So I think we should also have a parentResource() method on DAVResource that encompasses the urlForResource etc stuff. Again, the fast resources can override that and return their parentdirectly (they have self.parent defined) without needing to do a locateResource on the parent URL. -- Cyrus Daboo