LiveCode Forums

Hey all!

So, I've been working on a program lately for work, and I'm almost done (yay!)

I did however, have a couple of quick questions regarding how Livecode handles stuff. So, I've got a notepad file that Livecode can access over the network. I want to be able to access that and edit it (easy - already done). But, here's my question - how does Livecode handle that notepad file being edited if there are two versions of the program being run on separate computers who happen to access the file at the same time? I imagine if they only edit different lines, it won't be an issue, but if they edit the same line, what will happen?

At the moment, my thought on how to do it is to have a buffer system - so when computer A does its thing, it creates a separate text file with instructions on what to do (let's call it 1.txt), and when computer B does the same thing, it makes a new text file with instructions (2.txt). Then I have a separate program that every 30 seconds or so, checks that folder for any text files and edits the row number given in 1.txt, deletes it, then goes to 2.txt and so on until there's no more instructions for it to do. Is that something that would work, or is there a better way to do it other than have it update every 30 seconds?

Howdy, Opaquer,

This is one of those common problems that open a can of worms - your solution is going to be dependent on your level of skill and experience. For example, I would do this using a database and a database server, but if you don't know how to manipulate/use databases and/or database servers, that is not something you can accomplish.

Yes, your solution is one way to deal with the problem. Keeping a separate file for each user, and then a central app (the referee) that deals with the conflicts, is one way to solve it.

Issues you will encounter with this solution that you have to consider:
1) What if users make changes to the same record
2) What happens when you get to 3, 5, 10 users (if that is a possibiliity)
3) Syncing changes to the clients (the users)
4) Rules for resolving other conflicts that the referee app may encounter
5) The referee app runs into trouble and quits/stops operating

Good luck with it, and you know where to find us when you have questions...

Using text files in this case seems to be asking for trouble. I think a database is the best option here. It may seem daunting, but setting up a MySQL database isn't too difficult once you've wrapped your mind around the basics. If you are interested in trying out a MySQL database without setting up the server, there is a service here that offers a small (5mb) MySQL database for free:

http://www.freesqldatabase.com/


Here is an SQL Cheat sheet:

http://www.w3schools.com/sql/sql_quickref.asp

I really think it would be worth your time to learn about databases, as I truly feel it will help you avoid major headaches down the line.

One common solution is to use a single text file on the server that serves as a flag. The content of the file isn't important, you can also just use its existence as a flag. It's just a semaphore that is either on or off.

When one user wants to update the master file, you first check to see if thek semaphore file exists (or if the file is permanent, whether it contains a flag like "1" for "in-use".) If so, the script waits a few milliseconds and continues checking until the flag is cleared, the app then sets the flag, writes the update, and then unsets the flag.

There is still a slight risk that two users could find the flag unset at the same exact millisecond. A database would probably control that better, but if your user base is small and you don't want to install a database, a text file semaphore can work.

In just-pre-WWW days, one of my grad projects was called "Chat-O-Matic" (on Sun workstations/X11/Motif/Sockets) - it allowed multiple users in a WW team (in our case, a joint team with members in Pennsylvania, Australia, and Germany SW Eng courses) to chat in one window and edit a spec or requirements document simultaneously in another. The server served just the visible lines of the target doc that each user was currently looking at in their read/edit window, and saved that information in a server-local file (ie what Jacque said about a semaphore file). If a user went from reading to editing, that chunk of the file was marked as locked by the server, and other users were disallowed from switching from reading to editing if that chunk was visible in their workstation. On the slight chance two users sent in the same or overlapping edited chunks, the server kept both and marked the conflict in the original document. (We were also tracking agreed and not-agreed paragraphs with an async voting mechanism, so that was the same mechanism for tracking conflicts - they turned into apparently unagreed sections that the server refused to publish as part of a final spec).

Even if you used a database, you would encounter the same problem.
When many users act on the same item (text, image, sound or else) in the same time, you encounter conflicts.
Database strategy design is usually to lock item being edited from other users.
You can void to use a supervisor program, like a server or a database, if you work with just one file.
Try this:
File in common is BigFile.txt

Computer A read file and last modification time of the file and store it. Users modify the content. Computer A, before writing BigFile.txt check again last modification time of the file; if last modification time of BigFile.txt is different from the stored one, software advices user of conflicts and asks what to do.

This is the best strategy.