[cvs] [Wiki] changed: Project/ResourceLocking

[Ben Klang]

bklang  Tue, 06 May 2008 10:28:37 -0400

Modified page: http://wiki.horde.org/Project/ResourceLocking
New Revision:  1.10
Change log:  refine project goals, spelling & grammar

@@ -3,23 +3,33 @@
 [[toc]]

 +++ The idea

-> [http://lists.horde.org/archives/dev/Week-of-Mon-20050606/018056.html I
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 none is
working on this. So I decided to solve this problem.
+> [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.

 +++ Two ways

-> There are (a least) two ways how this can be done. **Locking** The easy
one is to lock an item for a certain time when someone starts to edit it. If
someone else tryes to edit it, horde will deny this and tell him / her to
wait. The contra of this is that only one person can edit one item at one
time (not very good for a groupware). **Try to merge** The better way would
be that horde tryes 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.
+> There are (a least) two ways how this can be done:

-+++ New Work
-> Since I needed a mechanism to lock resources for full WebDAV
functionality I have written a Horde_Lock subsystem.  Hopefully it will be
in CVS HEAD soon.  This subsystem is capable of locking arbitrary resources
identified by URI.  The locks support timeouts and exclusive vs. shared
semantics.
+> **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.
+
+> **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.
+
++++ 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.

 +++ 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.
+
++++ 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
-* write Horde_Resource_Locking to to get, set, delete and purge locks
(backend will be datatree)
 * add Method to merge Data
-* do test implementaion in nag
+* do test implementaion 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