another multi-user "solution"?

Gordon Tillman got at mindspring.com
Sun Apr 24 12:12:07 EDT 2005


Howdy Kurt,


On Apr 24, 2005, at 08:43, Kurt Kaufman wrote:

> This morning, while in the shower of course ("Mr. Kaufman, the U.N. 
> has decided to elect you Secretary General, on the condition that all 
> of your decisions regarding this institution are made whilst you are 
> in the shower.") I thought of another possible Rev-only solution to 
> the problem of allowing multiple user access to data.
>
> Originally I had thought of two or more  "anchor" apps that would 
> subsequently open one of many data-record stacks.  But instead of 
> record-stacks, why not record-text-files? While opening a single text 
> file containing all of the records would effectively shut out any 
> other users from accessing the data, if that data was divided into 
> separate text files, one for each record, any number of users could 
> work on them (provided they were working on different records, of 
> course).  Plus, there would be the added advantage of easy manual 
> correction should one of the records become corrupted somehow.
>
> My needs here are very basic; the records do not have to interact in 
> any way; I don't have to do operations on any of the records in the 
> aggregate (else I could see how opening many records successively 
> would be cumbersome).
>
> Before I embark on this option, does anyone see any serious problems 
> with this method?

One potential problem - if you are relying on the filesystem's locking 
facilities to control access to files in a multi-user situation, then 
I'm guessing that the volume that holds these files must be made 
available to each of the client computers that is running your 
application.  But remember in that case that file locking is not a 
reliable mechanism on a network mounted volume.

If you don't want to use a database, one simple (and somewhat cool) 
solution would be to have a server stack or resource management stack 
running on your designated server machine.  This application would 
listen on a designated port.  When any of your client applications 
needed to access a shared resource they would open a socket connection 
with the server app, get or update the resource in question, and then 
close the socket.  So long as you don't have a whole lot of clients and 
you don't keep the sockets open a long time this would work just fine.

--gordy



More information about the use-livecode mailing list