Comment 7 for bug 637323

On Mon, 13 Sep 2010 23:17:56 -0000, Robert Collins <email address hidden> wrote:
> > But there's no way to totally get rid of this problem, because in the
> > limiting case it is the correct behavior. If you get data from revision
> > n of the web service, and then modify it and send your modification to
> > be processed by revision n+k, the web service _should_ reject your
>
> While its true that we've *implemented' this as 'gets data and sends a
> patch' I very much doubt that most consumer think of what they do as
> 'patching'. Creating a mailing list is not 'patching the team'. Other
> web services manage to evolve without all clients simultaneously
> breaking every time they change *anything*.

Creating a mailing list also probably not a PATCH operation in
Launchpad.

Certainly I agree that the way the API works doesn't make it conducive
to handling PATCH failures well:

  * In most cases you don't care about the initial state of the object,
    you only want to set a final state (set a bug to Fix Released say).
    I have at times implemented a "mark_bug_fix_released" function, then
    called it in a loop catching 412 and retrying.

  * The 412 gives you no information about what changed server side, or
    even which object you are acting upon, which isn't great for
    long-running scripts. I think raising an exception with the 3 states
    available would allow for more flexibility in clients.

Thanks,

James