One thing that is missing is in the docs a clear description of the
rules for disconnected access and tokens.  The whole bit about binding
of uuid to cuid and then cuid/acl checking and how that survives
disconnection/reset has never been clear to me.  It may be that a
'tech manual' for coda is needed - not internals, but in terms of the
behavior specification.

But I think my big problem is the way that objects in the cache become
invalidated when modified on the server, rather than only when the new
version ends up on the client.  I realize that writing such objects is
guaranteed to cause a conflict, but having them readable is better
than nothing.

Perhaps two changes would help:

1) not discarding the old object until the new object is in the cache.

2) an optional (perhaps default on) configuration variable which
   counts objects which are in-cache but have newer versions as
   lowest-priority hoarding candidates.

With a proper hoard config, and enough connectivity to hoard, things
work fine, and coda has successfully hoarded stuff for me without me
paying attention (save file on workstation, with notebook plugged in,
take notebook, later look for file off-ne without ever having planned
to or thought about it, and find it hoarded.

So I think the problems only show up in the flaky connectivity case.

        Greg Troxel <gdt_at_ir.bbn.com>