Thanks for your response Stephen. My comments below.

>     Juan> I've not found around there any benchmark or article about
>     Juan> CODA working with a bandwith as low as 64Kbps.
>
> I've done this, with speeds as low as 14.4kbps.  It works fine for me,
> but there are some things you should be aware of.  Coda works on the
> basis of full file caching, with simultaneous writes to all servers.
> First, that means that if the file changes on the server, the user
> will need to download the whole thing, which might take many seconds
> for a large Word file.

The files would be 100-150K in average. I think this should be fine.


> If the user is mostly creating files locally
> which then get uploaded to the server, and any updates are made by
> that user.

What did you mean here? That it should work well with users only uploading
documents?
Users would create some documents it should be desirable these documents
should be uploaded within one day. Users also would also search and open
other documents but not in an intensive way (eg. at least 5 or 6 documents ,
at most 10 or 12 documents while editing).
Would this work fine? What client cache size you think would be suitable?

>
> On the other hand, if different users are editing the same files, then
> you might be better off with a different method that only sends
> changes.

Which method would work for this? This is not the case, but I've seen out
there some things about sinchronizing file versions (consuming much less
bandwidth). Is there a solution for this with low bandwidth?.

> So if what you mean by "not intensive" is that any given user is
> unlikely to be repeatedly viewing a file that is changing on the
> server between views, Coda should work very well for you.

Yes, I didn't mean that but this is correct. It is not important a very
strong consistency.

Thanks a lot. This is very useful information for my project.

Juan Carlos