I thought folks on the Winie list might be interested in
some of the discussions relative to the "Lost Update"
problem on the Mozile (Mozilla In-Line Editor) mailing list.
See also:
http://mozile.mozdev.org/
http://www.mozdev.org/pipermail/mozile/index.html
I've tried Winie 0.9a and so far it works wonderfully on
Solaris 8 with Java 1.4.2.
Thanks for building a nice application and furthering
collaborative authoring on the web.
--EJ
_______________________________________
Eric R. Johnson
SunServices
Sun Microsystems, Inc.
Phone: (303)-272-5671, x75671
Email: eric.r.johnson@sun.com
_______________________________________
Forwarded message 1
This is probably going to be a long one, so please delete
if you're not interested. :)
As some list members may recall, I've been experimenting
with different options for gracefully handling saves
from Mozile to a PUT-capable webserver. The major barrier
to enabling collaborative authoring with Mozile is that a
stateless client like Mozilla/Mozile is prone to collisions
or the "Lost Update" problem (see below).
As I see it, there are a number of alternative solutions
to preventing or handling collisions. Some options rely
on Mozile, some conflict with it.
*What solutions are current list members employing?*
Anyway, the alternatives I see are:
1. Warning on Conflict. Supplement Mozile's simple PUT
with code/logic to issue a HEAD request, inspect ETags
and prompt the user in the event of an update collision.
(Essentially copying the logic of Winie/WebCommander.)
2. Punt. Place responsibility for managing conflicts on the
website admins & developers. In other words, leave it
website admins/developers to write or obtain server-side
app logic (as in a CMS) to prevent or handle conflicts.
3. Un-Reserved Checkout, Automatic-Detection and Manual
Resolution of Conflicts at Check-in [UCAD]. Use webDAV
server-side auto-versioning (as in Subversion) or similar
strategy to enable manual recovery from update collisions.
4. Reserved Checkout [RC]. Implement LOCK & UNLOCK in Mozile.
5. Reserved Checkout [RC]. Use a standalone application like
DAVExplorer to manage locking or resources for update.
6. Out-of-Band Communications & Social Agreements [OBC]. Limit
PUT permissions to only 1 or so people that can coordinate
updates & prevent collisions.
After experimenting with options #1, #3 & #5, I've found
that I most prefer option #1 (prompt in the event of a
collision). Option #4 is also interesting. Unfortunately,
I'm stuck with option #6 at the moment.
Here's what I see for pros, cons & questions:
1. Warning on Conflict. Prompt on collision (ETags)
+ ETags widely supported & easy to configure on
most free webservers (Apache, Jigsaw, TomCat)
+ Adoption requires no coding or additional CMS
products; Enables sysadmins to easily set up.
+ Seamless to users if no conflict. In other words.
manage by exceptions only (as opposed to proactive
LOCKing solutions).
+ Low/No overhead for conflict resolution by server
administrators
- Requires code contributions from busy volunteer
developer community
? Is this feature desired by the wider Mozile user
base?
2. Punt. Leave collision management to admins & developers
+ No overhead for Mozile's volunteer developers
- Lack of integrated solution to collisions may
prevent adoption by non-developers
? Opinions?
3. Auto-versioning & manual recovery from collisions [UCAD]
+ No overhead for Mozile's volunteer developers
- High overhead for website admins
- Lack of integrated solution to collisions may
prevent adoption by non-developers.
4. Reserved Checkout. Implement LOCK & UNLOCK in Mozile
+ *Should* prevent update collisions
- Would probably need to implement Mozile or server
logic to only expose editing functions when the
page/document is locked
- Requires multiple steps for every edit (uses
proactive management model as opposed to an
exception management model).
? This could be workable... Thoughts?
5. Reserved Checkout. Use a standalone app like DAVExplorer,
etc, to manage locking, etc
+ Robust prevention of collisions
- Why use an in-line editor at this point??
6. Social Agreements. Limit PUT permissions to only a very
small group of people that can coordinate updates & prevent
collisions.
+ Workable in small groups (especially groups of one)
- Prone to error & failure
- High potential for data loss
Obviously, the above is my opinion only. Hopefully, it is
instructive.
--EJ
References:
"Lost Update": http://www.w3.org/1999/04/Editing/
Winie: http://jigsaw.w3.org/Winie/
WebCommander: http://www.w3.org/WinCom/
Subversion: http://subversion.tigris.org/
http://svnbook.red-bean.com/html-chunk/apds02.html#svn-app-d-sect2.2
DAVExplorer: http://www.ics.uci.edu/~webdav/
Configuring ETags in Apache:
o Compile Apache with mod_expires (--enable-expires)
and mod_headers (--enable-headers)
o Add the ETag stuff to httpd.conf, like so:
<Location /p3>
DAV on
FileETag MTime Size
(some stuff deleted...)
</Location>
o Restart Apache
^Paul, etc, I thought you might be interested in trying this
Apache config. Not sure if mod_headers is needed, but
it didn't hurt anything to include it in my config.
_______________________________________
Eric R. Johnson
SunServices
Sun Microsystems, Inc.
Phone: (303)-272-5671, x75671
Email: eric.r.johnson@sun.com
_______________________________________