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
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
