[CalendarServer-dev] Re: [CalendarServer-changes] [1345] CalendarServer/trunk/lib-patches/Twisted/twisted.web2.dav.resource. pa tch

[Cyrus Daboo]

Hi Wilfredo,

--On March 9, 2007 9:50:46 AM -0800 Wilfredo Sánchez Vega 
<wsanchez at 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