zim-wiki team mailing list archive

[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