Thanks to everybody for the outpouring of ideas! I appreciate it! Here are some responses from me.
Quoting Dan McMahill <[EMAIL PROTECTED]>: > On Fri, Jan 21, 2005 at 07:51:19PM -0500, Stuart Brorson wrote: > > > Lockfiles will be simple ASCII text. Inside each lockfile, there will > > be the following (for example): > > ------------------------------------------------------ > > # This is a gEDA/gaf lockfile signalling that this .sch file > > # has been locked for editing. If you are sure that nobody > > # is currently editing this file, you may delete this lockfile > > # to use gEDA/gaf normally. > > # > > # user who locked this file > > user=sdb > > # process number of program creating this lock > > pid=345345 > > # program name which created this lock > > program=gattrib > > # time when lock was created > > timestamp=YYYYMMDD.HHSS > > ------------------------------------------------------- > > You may wish to also record the hostname of the system that > created the lock otherwise the pid may not be easy to do anything > with. Also you may wish to include a version number of the lock > file and perhaps the os/version of the system which placed > the lock. Good idea. I'll put the host name in there too. > Also what do you think about automatic expiring of locks? > For example if a program has a lock, it is required to once an > hour update a time stamp in the lock file. Then perhaps > if a time stamp is more than 2 hour old the lock file is > declared invalid. This may help with the problem of stale > lock files being left around if a program crashes or a > computer or network goes down. Automatic expiration is getting too complicated for me. I understand the problem you wish to avoid, but I think that the file-based mechanism is simple enough that the user can just go and delete the lock file if there has been an abnormal program termination or a network failure. Remember -- I am not the world's greatest programmer, so I try to keep things simple. Some other points: * Joshua suggested incorporated including the pid into the lockfile name. My questions is: Why? Using only the schematic.sch.lock filename makes the lock independent of which program or which pid created the lock. Then, any program which wishes to write the file must only look to see if the corresponding .lock file exists. If I stick the pid in the filename, then I need to look for any file of the form schematic.sch.*, which is a grep-style operation on the whole directory from within a C program -- kind of a PITA if you ask me. That's not to rubbish the idea. Rather, I am wonder what the advantage is of having the pid in the filename. I do realize that other unix programs do this, but I don't know why they do, or what the advantage is. * As for the multiple suggestions to integrate this into a CVS type system, I think that CVS is meant to solve a different problem. CVS is meant to maintain different versions of a particular file, whereas my simple lockfile scheme is meant to prevent multiple programs from colliding when saving out .sch files. Yes, in the grand scheme of things, CVS also has facilities to handle version skew and merges between different file versions, so the problems have some commonality. However, here are my points about CVS: 1. Integrating CVS into gEDA/gaf's save system seems like a very complicated coding job. Again, I am not the world's greatest developer. I just play with this stuff for fun. Therefore, I eschew complexity. I also believe that most simple things can be made to work, whereas most complicated things are doomed to remain forever buggy. 2. Requiring users to have CVS up and running alongside gEDA/gaf would be a major turn-off to many (perhaps most) gEDA users. I'd hazard to guess that most gEDA users are students or hobbiests who just want to draw schematics. They don't want to deal with CVS. Many of them probably don't even know what it is. Those who do want to use CVS can check stuff in manually -- which is what they are already doing. Comments? Stuart
