> 	Also, I promised a "optimizing coda 6" document and I have a draft of
> it.  I'm attaching it in rtf format in case it is useful to someone.

Thanks Patrick,

a nice document and a good summary.

I have a remark (where I think you rely on my own post)
"Volumes are used as administrative units to specify
owner and group permissions, quotas, backup strategies, etc."

There is a couple of things to formulate differently:

- the "owner" has no meaning on Coda, and the corresponding "access bits"
are abused in a controversial way (they limit access to the file for all,
but are not enforced by the servers, so anyone with a modified client can go
around that access "limitation") so it is best to ignore them for all purposes
except cosmetical

- "group" bits are totally irrelevant on Coda, ignore
(Coda groups are totally different from Unix ones)

With other words, there are no "owner and group permissions".

- real access control is done via ACLs (access control lists), and they are
per-directory, not per-volume (nor per-file).

I referred once to a setup where I have 4 volumes per user,
having different backup strategies, different quotas
and also different default ACLs on their root directories. I would not
_have_ to separate volumes for the last reason,
it could be done inside one volume. The main idea was to separate
different kinds of data into separate volumes.

Another issue:

The size of RVM on the client is calculated very differently compared
to one on a server. Venus allocated RVM not only for files or directories,
but also for file changes which can happen in disonnected mode. It makes
the client a lot more RVM-hungry than the server for the same amount of data
(number of files and directories, which on the other side is usually a lot
higher on a server than on a client)

Again, I think your document is very useful.

Regards,
--
Ivan