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

Adrien de Croy wrote:
> [...] the PATCH command won't work since the entity will have changed before 
> the patch gets there, so that patch will fail, and the UA will have to 
> cope with that.  In the patch case it's first in wins.  Everyone after 
> that has the wrong E-Tag.

It depends on the type of PATCH.  For example, an "append" operation -
or more complicatedly "append this paragraph to my simple blog file".
Both of those can be forms of PATCH which succeed if the original
entity is changed meanwhile.

Perhaps not coincidentally, those forms don't always need an Etag in
the request, either.

> If you have Last in wins, then you get a history on the server of all 
> mods, and each is coherent in itself.  If you have first in wins, you 
> only get the first modification, and no history to roll back if you need 
> to resolve conflicts, plus a bunch of UAs that have p*ssed off users, 
> since their change couldn't go in, and the UA isn't smart enough to:
> 
> a) get a fresh copy
> b) try and re-apply the "changes" that the user made to the last copy in 
> the context of the new one (flawed concept).
> c) try and re-submit it.
> 
> even if that would be a "smart" thing to do.  So the user loses their work.

In my experience, that last-in-wins-with-history results in lost work,
because it succeeds for all users but most of them aren't notified
that their work is dumped _only_ in the history file (assuming you
have one).  They send in their work, get a successful response, assume
they don't need to do anything more, and move on to something else.
They think their work is finished with, but it's effectively lost
because nobody is ensuring it reaches the place that matters.  It's
recoverable, but that is not enough.

> There's a reason why version control software uses last-in-wins 
> (sometimes with merging for conflicts), you can roll back to the version 
> you want then.

In my experience version control software uses first-in-wins and
everyone else has to resync and fix conflicts locally before they can
submit their changes to a shared server.  CVS and SVN work this way,
for example.  What VC software are you thinking of?

-- Jamie

Received on Sunday, 9 September 2007 11:56:03 UTC