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

Yaron Goland wrote:
> This assumes that the client has an etag for the resource, in many of our use cases they will not. So the if-none-match approach will often fail.
>
>   

I don't know how any sane UA could even begin to contemplate a PATCH 
command if they didn't have an E-Tag for what was being patched.

My own 2c on trying to avoid race conditions, patching et al.

It sounds to me like trying to solve an application problem with the 
protocol. I think the problem if it even deserves to be solved should be 
done in the heuristics of the UA/Server rather than trying to deal with 
it in the protocol where I seriously doubt it can be resolved anyway.

If you have many UAs patching the same entity rapidly (as in some blog 
software which re-writes files), then the concept of getting back the 
patched version you patched is somewhat sketchy.

when you have multiple users trying to submit their copy of what they 
think they have...  Personally I think it's a recipe for disaster, since 
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.  "Normal" or "Expected" case however is last 
in wins, i.e if you write a UA and you want your user to "win" the patch 
race, then you submit the whole resource, not a patch for it, because 
that's the only way you can guarantee that the server will receive a 
coherent entity from your command that it can put into its history log 
when the next mod comes in.

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.

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.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Saturday, 8 September 2007 06:57:11 UTC