On Fri, Sep 24, 2004 at 12:18:59PM +0900, Stephen J. Turnbull wrote:
> >>>>> "Troy" == Troy Benjegerdes <hozer_at_hozed.org> writes:
> 
>     >> I still like the idea a lot, I'm just trying to be prepared and
>     >> know all the problems that might show up before actually trying
>     >> to implement something like this.
> 
>     Troy> I think a lot of the issues that got brought up will be
>     Troy> handled by David Howell's cachefs. [...]
>     Troy> Then we can keep Coda focused on the disconnected operation
>     Troy> problem instead of getting lost in cache ;)
> 
> 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.

The additional restrictions on cache semantics is keeping track of what 
has changed that the server hasn't seen, and resolving conflicts with the 
server.

As a first step, I think it is reasonable (and good for our sanity) 
to block writes until the whole file is in cache. The hard part that
requires proof is dealing with writes.

The way I understand cachefs, the user would open say, an MP3 file
through cachefs, we'd get to trap the open like we do now, but instead
of fetching the file on open, we could defer fetching until we get a
'read block' call from cachefs, in which case we just fetch the block
cachefs wanted.

I am of the opinion however that cachefs is not going to provide
sufficient semantics for writes without the whole file present. I don't
think it's worth worrying about.. I can't think of very many situations
I would actually *want* to be able to write without requireing the whole
file be present, but there are a ton of situations where I want to be
able to read without waiting for the whole thing.