(Illustration by Gaich Muramatsu)
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>Received on 2002-03-01 08:03:29