- From: Tobias Giesen <tobias@tgtools.de>
- Date: Tue, 12 Jun 2007 18:04:09 +0200
- To: w3c-dist-auth@w3.org
Lisa wrote: > - 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? Personally I don't have a problem with this scenario, as my customers use only one client software (mine) and I know that it's capable of setting the local timestamp. So Client B will know that it needs to download files even if their timestamp is older than the last time Client B did a synchronization. It will make its local timestamp identical and will not constantly see any mismatch. So, one custom property containing the true last edited/modified timestamp would be sufficient for me. I will try it and hope that the WebDAV servers will accept it and actually store it. Cheers, Tobias
Received on Tuesday, 12 June 2007 16:04:22 UTC