zim-wiki team mailing list archive

[João Santos <jmcs@xxxxxxxxxx>]

Wouldn't this module: http://packages.python.org/lockfile/lockfile.html do
the job?
As for stale lock files the easiest way to solve it is to allow the user to
override them, but having a timeout value would not be a bad idea.

2012/3/1 Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>

> On Thu, Mar 1, 2012 at 10:35 AM, João Santos <jmcs@xxxxxxxxxx> wrote:
>
>> I think the easiest way to implement this is by doing the following:
>>
>> 1 - User A opens a page. A lock file with a unique ID is created;
>> 2 - User B tries to open the same page, it opens read only with a message
>> saying that file is being edited and giving the user the option to override
>> (this allows not only for the user to override another user, but also to
>> solve the problem of zim crashing without removing the lock file).
>> 3 - If User B overrides the write block the lock file content is replaced
>> with his unique ID, and user A is presented with a message saying that
>> editing was blocked by another user, and also giving the option to override.
>> 4 - When the user that leaves the page the lock file is deleted, one of
>> the read-only users (if any) creates a lock file, in a way similar to
>> CSMA/CD (basically a race to create a new lock file).
>
>
> Looks like we have a volunteer to work on this ;)
>
> Complexity comes in having a atomic lock system. Especially windows does
> not have the atomic "rename", so there is no way to ensure you got the
> lock. Will need a bit of code for fallback scenarios. See the code in fs.py
> to deal with atomic write on windows.
>
> Another thing to consider is how to deal with lock files that are left
> behind if a process crashes etc. -- have them time out after a certain
> interval ? (Requiring live applications to refresh the locks every once in
> a while -- say each auto-save ?)
>
> Even with all that in place, it only solves the use case for a small
> number of users (ay 2 or 3). It will not scale well to larger groups. But
> that is not the intention in any case. For supporting larger groups we
> really need to go with version control + a conflict resolve mechanism.
>
> -- Jaap
>
>
>