Jim Rees wrote: > Simon Wilkinson wrote: > > *) Data consistency is interesting. If a server breaks a callback, no > attempt is made to update the clients cache. If the client > subsequently goes disconnected, then that cached data will be made > available to the client, regardless of how the data on the server > changed. This is definitely sub-optimal. > > I think you're being way too conservative here. To provide the kind of > guarantee you are suggesting you would need to obtain and return callbacks > on everything in your cache before you disconnect. That could be thousands > of files. Most servers won't give you that many callbacks simultaneously so > you would be open to races. Disconnection would take a long time and > present a large load on the server. And you would be unable to go into > disconnected mode if the network unexpectedly went away, thereby losing one > of the nicest features of disconnected mode.
Failure to perform data verification before disconnecting means that you will be at risk of data corruption due to inconsistency in your data. You do not need to have all of the callbacks at once. You can perform your check and mark files/directories disconnected a bit at a time. You are going to need to verify you have the entire file / directory in the cache anyway before you disconnect. Otherwise, the contents are useless. In my opinion, the disconnected mode that was implemented is not ready for end users. It is only useful to super users who understand all of the limitations and dangers of its use. What end users require is the equivalent of the Windows Offline Folders functionality in which the user specifies a list of directories and files that are to be kept in sync. They are sync'd when going off-line, when going on-line, and periodically while on-line to optimize the cost of the sync when going off-line. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
