Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]

On mån, 2007-09-10 at 11:03 +1200, Adrien de Croy wrote:
> right - in other words, the only way to guarantee security on the patch 
> is to LOCK, in which case why even bother trying to solve race 
> conditions around the PATCH command.  The race condition if anywhere is 
> around who gets the LOCK first...:)

Why?

For very many applications "fail gracefully on concurrent edit" is the
preferred mode, allowing the application to fall back on merge and
resubmission of the update. On a larger scale this is also less error
prone unless there is lots of interest in authoring the exact same
resource.. There is generally less loss in productivity from the
overhead of having to deal with a merge when a concurrent edit should
happen than having to fight with stale locks which is far more common.

And even with locks the application should be capable of handle merges
in case the lock has timed out or been overridden, at least if the lock
is held over any longer period of time (minutes or more..) which is
generally the case when there is humans involved..


Sequence "fail gracefully on concurrent edit" is simply

GET

[edit]

PATCH with If-Match.

[if error, perform a merge of the changes]


The LOCK sequence is only needed if the application wants to try
blocking others from even trying to author the same resource at the same
time.


Regards
Henrik