Hi Wilfredo,
--On March 9, 2007 9:50:46 AM -0800 Wilfredo Sánchez Vega
<[EMAIL PROTECTED]> 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
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/calendarserver-dev
