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

Jamie Lokier wrote:
> 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.
>
>   
Why wouldn't you just use a form POST for such an operation?

> 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.
>
>   
Fair enough.  Just still trying to think of what a poor UA / user would 
do once they've been told their patch won't be accepted because the 
thing they are patching has been changed out from underneath.

>> 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?
>
>   
er.... VSS, with multiple-checkouts enabled

%-P

Adrien

> -- Jamie
>   

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

Received on Sunday, 9 September 2007 12:38:38 UTC