> What you really need is a way to ask the server "can I > cache the following?" and have the server say yes or no > and then have some way to invalidate the cache, so that > you get coherent behavior, even in the above case. > We discussed various ways to add this to the protocol > but ultimately we didn't see any way that was simple > enough that the specification effort wasn't outweighed > by our not needing to solve the problem at that time.
Do you recall what the issues were? Wouldn't something like load-linked/store-conditional suffice if the common case is a single writer? When the client does a "read-linked" call, the server sends an ID along with the data. The client can then do a "write-conditional" by passing the original ID and new data. If the ID is not valid anymore (if someone else wrote in the meantime) the write fails. The server doesn't have to keep any client state or inform anyone about an invalid cache. Of course, if any client fails to follow this protocol things fall apart but at least well behaved clients can get coherency. And this would work for cases such as making changes on a disconnected laptop and resyncing to the main server on the next connect. You wouldn't use this for synthetic files. This ID can be as simple as a file "generation" number incremented on each write or crypto strong checksum. As someone (Terje Mathiesen?) said all programming is an exercise in caching.
