Re: PROPPATCH question (setlastmodified)

On Jun 12, 2007, at 7:15 AM, Tobias Giesen wrote:

>
> If I can't change the "getlastmodified" attribute, can I store a  
> custom
> attribute like "mytimestamp"?

That may be a better choice if the basic approach works since so many  
servers treat getlastmodified as their own storage timestamp with a  
protected value.

Do you ever have a use case where multiple clients want to sychronize  
the same data, as is commonly done with source code repositories for  
example?  If so, then neither "getlastmodified" or a custom property  
really works.  Where T is the timeline:
  - T: Client A acquires some files locally with timestamp T
  - T+1: Client B synchronizes from the repository
  - T+2: Client A uploads file and sets timestamp T in order to match  
up to local timestamp
  - T+3: Client B relies on ETags for synchronization we hope,  
because otherwise the new file will show up as if it has already been  
synchronized...  even if client B successfully downloads these files,  
do we know that it's capable of setting the local timestamp or will B  
constantly see a mismatch between its local timestamp and the server's?

If every synchronizing client needs a different value timestamp to  
match the time they first acquired the file (downloaded from the  
shared repository or acquired from elsewhere) then you could still  
use custom properties with the username in the property name, but it  
might get pretty unwieldy.

Another option as you point out is a database.  If a full backup/ 
restore system is desired, the clients could each create a "synch  
file" on the server that has the timestamps and other information  
needed to reconstruct the backed up data.

Lisa