>
>
>I'm at the edge of my knowledge; I think if you want more information
>you need to get Jan in the conversation.  
>
He's in the ML too no ?
I recognize I avoid writing him directly considering his time precious 
for coda evolution.
And he always take the time one day to read the ml and write some responses.

>He'll probably want to know
>why you want to avoid the disk cache.  (After all, if you can afford
>1GB RAM, the cost of 1GB disk is negligible, so presumably there's
>something about the semantics of disk access you want to avoid.)  
>
Probably that...

>It's precisely features like
>persistence of RVM and the management of the file cache, management of
>data structures that allow disconnected operation, etc that make Coda
>so complicated.  This is all done by the client, and must be done by
>the client because of disconnected operation.
>
Yes....
However I really find the idea interessant....
Disconnected mode is a wonderful thing for loptop file management.

Considering now a full "server" machine configuration, trying to improve 
venus stability....
I get some troubles... Morevover I've observed that venus generaly 
writedisconnect from most volumes when one volume is heavy touched and 
turn into disconected state ... (One time I get all volumes disconnected 
exept the one I was stressing, but one of my own cron-script, trying to 
resolve trouble, did a coda-client restart, and finished to push venus 
from knees to floor. I admit I have to improve on venus understanding, 
auto-managing, debuging... Wow....)

Coda has proved to all we could preserve from network troubles such as a 
cable disconnection, hub troubles, network latency.....etc...
- Assuming only one swith well working beetween venus and codasrv.
- Assuming that if the 2 or 3  replicated codasrv-machine are down venus 
will not deserve data.... ( no hoarding )

How is the rvm-less venus stability / behaviour ?
Has someone tested it ?

What are the server-side replication implications of venus-rvm ?
You were speaking of mutation.
If I remember correctly venus fetch files to the fastest server to 
response his request.
And then servers replicate to themself data....
Otherwise, in case one serveurs is down for maintenance during 15 
minutes, imagine a laptop syncronize his files cache with volume in the 
meantime, and then the user get disconnected before serveur fire 
up....When would replication start ?

I think a risk arize if venus crash during fetching file to server in a 
rvm-less config....
All data in memory of venus machine would be lost !
On codasrv side, on the server that trigger fastest to response venus 
call, as the update was not finished he would not change data on the 
volume, or...... or did I point the mutation ?
Is that the server side conflict ?
This would only be one or few files on specific volumes so would it fire 
codasrv in crash ?

-- 

Lionix
FS-Realm (newbee?) Administrator
Hundreds hours of work but so powerful !
And still have to work :o)