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
|