>>>>> "Juan" == Juan Carlos Schroeder <jcsc_at_adinet.com.uy> writes:

    Juan> But (thinking about using less bandwidth) as the clients
    Juan> will be located in LANs of 4 or 5 computers (all them
    Juan> clients), can't the clients use local LAN cached copies of
    Juan> the files?

No.  You could set up a server on the LAN, but it sounds like you
don't want to do that for some reason.

    Juan> Would this be a good improvement in bandwidth?

Of course a local server would give better bandwidth for local users,
but it won't affect the bandwidth needs to upload to the central
server.  You could also have no central server (you do need an SCM to
hold the directory of servers, but that can be any server; it does not
need to hold all the files), but local servers which replicate a
subset of peer servers.  This would be more complicated, and again the
bandwidth constraint would be on the remote server(s) you replicate
to.  Finally, you could just have every server serve only local files,
but then if the server crashes you lose access to all files on that
node.

    Juan> The last thing I have doubts on is how the clients will
    Juan> share the bandwidth and how to synchronize with the server.

This depends on how often writes are taking place.  It shouldn't be a
big problem unless you enough clients in one location that the average
time between writes is a small multiple of the average time it takes
to write.  To get better bandwidth sharing you need (1) block at a
time writes over the network and (2) editor software that knows how to
use it, but as far as I know no such editor is available; I don't
think Word works that way.

    Juan> How do I avoid the clients going to "write-disconnected"
    Juan> mode having bandwidth as low as 64KB (and also shared
    Juan> between them)?

AFAIK, "disconnected" is what happens if you're bandwidth-starved.
That means that Coda thinks you can't reliably transmit files either
way.  "Write-disconnected" is something that happens when writing is a
bad idea, ie, there is a conflict on the server.

IIRC, Coda doesn't ask for an absolute level of bandwidth; it asks for
consistent bandwidth.  So if it's used to getting 64K, and suddenly
(because another client starts writing) it gets 1K for a period of
time, you could go disconnected.  But I don't remember going write
disconnected on my 14K link unless I tried to do something the took a
lot of bandwidth while Coda was reintegrating.  In the case of a
bandwidth shortage, I believe that Coda should eventually reconnect on
its own, and then will automatically reintegrate.

The use pattern that seems likely is User A edits on Monday, goes
disconnected, shuts down, boots on Tuesday, Coda finds bandwidth,
reintegrate, and User A's edits are now available to other Coda users.

If that's "good enough", great.  If not you could teach the users
(maybe a Word macro, can Word execute shell commands?) to use a simple
command "cfs cs" or "cfs fr" to force reintegration.  Or schedule it
to execute every hour on the hour in the task scheduler.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free s