Re: Question about DAV:getlastmodified property

>
>> PROPPATCH on DAV:displayname also not change the modification date of 
>> a
>> resource? What about acquiring a LOCK or setting ACLs on a resource? 
>> Has
>> anybody created a list of properties which should lead to an update of
>> the modification date, if they are changed? Should changes to dead
>> properties always lead to a change in the modification date?
>> regards,
>>    Heiko Weber
>
> In general, the only thing clients can rely on is that *if* 
> getlastmodified is present, it will change anytime the GETtable 
> content changes (within timer resolution...). So on the other hand, 
> servers have a lot of implementation freedom, as long as they don't 
> break that contract.
>
Julian's right, and there's another couple things to point out: while 
servers have a lot of implementation freedom, there are couple things 
to consider particularly when interoperating with HTTP clients unaware 
of properties.

1. Consider whether your getlastmodified will be changed everytime the 
ETag changes -- or perhaps you're not supporting ETags.  If they change 
together or ETags aren't supported, then there are cache update and 
lost update considerations (2 and 3).  If the getlastmodified and the 
ETag change at different times, then that might not cause problems but 
they do need to be considered separately.

2.  HTTP clients refresh their caches of resource bodies using the 
getlastmodified date (or the ETag if that's available and they feel 
like it).  If the getlastmodified date changes whenever properties 
change (or ACL or lock state), then HTTP clients will have to download 
the resource body unnecessarily.  That might not be a problem if 
properties change rarely or if resource bodies are small, but it is 
certainly the minimalist approach to change the getlastmodified or ETag 
only when the body changes.

3.  WebDAV clients (and possibly even HTTP clients) use the 
getlastmodified date (or the ETag) to determine whether they can take 
local changes and apply them to the resource, or whether the local 
changes will conflict with changes made by another user since the 
resource was downloaded.  If the getlastmodified date changes because 
of property value changes, then the client might have to throw away 
resource body changes unnecessarily.   I'd say that the ETag SHOULD NOT 
change when the lock state changes because WebDAV clients use that to 
see if they have to throw away changes. And that means that if the ETag 
and getlastmodified behave the same way then getlastmodified shouldn't 
change either.  (Consider the case where a client LOCKs and UNLOCKs the 
resource without changing anything.)

Note that the problem of telling when properties change is completely 
unsolved.  Clients can't rely on getlastmodified or ETag because some 
servers don't change those when properties change.   It's pretty well 
unfeasible to support offline use and synchronization of a decent 
number of actively changing properties without some extension.

Lisa

Received on Thursday, 17 February 2005 18:00:28 UTC