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, TobiasReceived on Tuesday, 12 June 2007 16:04:22 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:15 GMT