>>>>> "Troy" == Troy Benjegerdes <[EMAIL PROTECTED]> writes:
>> Say what? In terms of the file contents, disconnected
>> operation is just a set of additional restrictions on cache
>> semantics, no? I would be surprised if a general facility like
>> cachefs will satisfy them out of the box. It's possible, but
>> requires proof. There's a pretty good chance that proof itself
>> will be on the order of difficulty of generalizing venus.
Troy> The additional restrictions on cache semantics is keeping
Troy> track of what has changed that the server hasn't seen, and
Troy> resolving conflicts with the server.
And ensuring file integrity for disconnected operation. In other
words, venus needs to know everything that cachefs knows about what's
cached.
Furthermore, I can imagine applications that really want to assume
that the whole file is available before they get to work, even though
the data in Coda may be read-only for that application. Currently we
don't need an API for that. With your scheme, we do, to account for
situations where we go disconnected while a file is open for read.
Troy> The hard part that requires proof is dealing with writes.
Writes are the hard part, yes, but they are not the only thing that
requires proof.
Troy> I can't think of very many situations I would actually
Troy> *want* to be able to write without requireing the whole file
Troy> be present,
Any "blind" append. Files bigger than cache (think handhelds). A
database application might want to do it. Journaling file systems
already do it fairly generally in a certain sense.
Troy> but there are a ton of situations where I want
Troy> to be able to read without waiting for the whole thing.
Sure. You're impatient to read. Other users/applications will be
impatient to write.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
