[cvs] [Wiki] changed: Project/ResourceLocking

[Ben Klang]

bklang  Tue, 20 May 2008 22:38:49 -0400

Modified page: http://wiki.horde.org/Project/ResourceLocking
New Revision:  1.13
Change log:  rewrite project info and update status

@@ -3,42 +3,36 @@
 [[toc]]

 +++ The idea

-> [http://lists.horde.org/archives/dev/Week-of-Mon-20050606/018056.html
Martin Lohmeier noticed] that there is currently no way horde can tell you
that anyone is already editing an item when you try to edit an item (notes,
wiki, etc).
[http://lists.horde.org/archives/dev/Week-of-Mon-20050404/017589.html Kevin
Myer] asked the same question a few weeks ago on the dev list, but no one
was working on this. So he decided to solve this problem.
+> One of the core concepts of Horde is the ability to collaboratively
create and share information.  However there is no technical means to
prevent users from stepping on each other when modifying shared resources
(such as Wiki pages, tasklist or calendar items etc.).  The goal of the
Horde_Lock project is to create a library that allows an application to
request and manage locks on resources it manages.

-+++ Two ways
+> The original driver for this library is the evolving !WebDAV support in
various Horde applications.  Horde can not claim !WebDAV class 2 compliance
without a mechanism for managing and respecting locks.  It quickly became
clear that these locks could be used outside !WebDAV to good effect on all
shared Horde resources.

-> There are (a least) two ways how this can be done:
++++ Conflict Resolution Strategies

-> **Locking** The easy one is to lock an item for a certain time when
someone starts to edit it. If someone else trys to edit it Horde will deny
this and tell him / her to wait. The disadvantage of this is that only one
person can edit one item at one time (not very good for a groupware). 
However there is additionally the concept of a "shared" lock which may be
useful with the next strategy.
+> There are (at least) two ways to prevent conflicts when editing shared
resources:

-> **Try to merge** The better way would be that Horde trys to merge the
changes, similar to cvs. If changes cannot be merged, Horde will tell the
user. I think this is what I'll try.
+> **Locking** The easy one is to lock an item for a certain time when
someone starts to edit it. If someone else trys to edit it Horde will deny
this and tell the user to wait. The disadvantage of this is that only one
person can edit one item at one time which on a popular system may be
cumbersome.  However there is additionally the concept of a "shared" lock
which may be useful with the next strategy.

-+++ New Work - May 2008
-> Since I needed a mechanism to lock resources for full !WebDAV
functionality I have written a Horde_Lock subsystem.  The work to date has
been committed to Horde CVS HEAD.  This subsystem is capable of locking
arbitrary resources identified by URI.  The locks support timeouts and
exclusive vs. shared semantics.
+> **Try to merge** An improved approach would be to allow Horde
applications to try to merge the changes two users make similar to source
control software. If changes cannot be merged automatically Horde will
notify the user. Horde_Lock will make no attempt to implement merging as
this is highly application specific but is designed to allow applications to
use the shared lock concept in concert with a merging strategy.

++++ Project Status - May 2008
+> Since a mechanism is needed to lock resources for full !WebDAV
functionality a new Horde_Lock subsystem has been merged into Horde 3.2. 
This subsystem is capable of locking arbitrary resources identified by URI
and grouped by scope.  The locks support timeouts and exclusive vs. shared
semantics.

 +++ The API
 > The API has been published in the Horde API documentation.  Anyone
interested in this project is invited to review the following URL and
provide feedback to the Horde Dev mailing list.
 > http://dev.horde.org/api/framework/Horde_Lock/Horde_Lock.html

 +++ TODO

-* Stabilize SQL driver
-* Implement all semantics required to be RFC-compliant for !WebDAV locks,
with an eye toward using these locks in other Horde applications.
+* Stabilize SQL driver (mostly done, more testing is necessary)
+* Implement all semantics required to be RFC-compliant for !WebDAV locks,
with an eye toward using these locks in other Horde applications. (Done and
implemented in Horde_RPC_webdav class)

 +++ Wishlist
 > These are potential uses for the Lock system that have been requested or
proposed by others.

-* write Text_Patch to use diff's from Text_Diff
-* add Method to merge Data
-* do test implementaion in Wicked
+* Implement in Wicked
 * Create admin UI to view current locks and manually remove them.
-
-+++ Timeline
-* June 6th, 2005 Idea for this project
-* June 24th, 2005 add TODO, start coding
-* May 5th, 2008 Project ownership moved to Ben Klang

 +++ Contact
 > Ben Klang <ben at alkaloid.net>