Comment 6 for bug 637323

On Tue, Sep 14, 2010 at 10:22 AM, Leonard Richardson
<email address hidden> wrote:
> I see. Right now the ETag change whenever the code revision number
> changes. We can make it so that the "revision number" is a number we
> control and only increment when we actually change the web service. That
> will reduce this problem, but it won't totally eliminate it, and it'll
> mean that every Launchpad developer has to remember something extra.

What does including the code revision in the ETag do for us?

> We have a plan to freeze old versions of the web service (eg. "beta" and
> "1.0"; currently backward-compatible changes bleed through to earlier
> versions because it's easier than making sure they don't). Once we do
> this, we could associate a revision number with each version of the web
> service. Since the frozen versions would change very very rarely, you
> would pretty much never get this error as long as you were using a
> frozen version. You would get it more often if you were using devel,

Here's the challenge:
 - rollout 10 times a day, one-two commits a rollout
 - no observed downtime.

> 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*.

> request. It can't be expected to handle that request correctly, because
> it relied on assumptions that are no longer valid. It doesn't matter
> whether your two requests are separated by three months, across several
> Launchpad rollouts, or by a few seconds during a rollout. And of course
> if you get data from revision n+k and send it in to be processed by
> revision n, there's absolutely no hope.

Perhaps we need to redesign the web service fundamentals then? I don't
know how deep this assumption goes.

-Rob