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

[Wilfredo Sánchez Vega]

On Mar 9, 2007, at 10:13 AM, Cyrus Daboo wrote:

> 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.

   If you didn't obtain it from the request, you can't call  
urlForResource() and expect it to work.

   If you got a resource via the group-membership lookup, then you did  
not get it from a request and therefore should not expect the request  
to know it's URL.  In that specific case, you do know it's a  
principal, and that you can call principalURL() instead.

   The Twisted code in question is buggy is if makes the wrong  
assumption.

> 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.

   I think this encourages the broken assumptions I mentioned above,  
since resource.url() would only work in the same cases, except for  
certain types of resources.  For most resources, it would break in the  
same way.

> 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.

   Again, this isn't appropriate for DAVResource, most subclasses of  
which don't actually have the information needed to return the parent  
resource.  url() and parent() are only feasible in a statically  
configured schema.

   We do have that for some of our resources, so it might make sense  
to have a mix-in class that has a faster ACL lookup implementation  
which uses the parent and url attributes instead of locateResource(),  
etc.  But let's not add API to the base class which can't be  
implemented by all subclasses, which will certainly lead to buggy code.

	-wsv