A minor detail. The server expects to receive a revision number which MATCHES OR EXCEEDS the stored number. I thought it was easier to deal with things this way. Keeps incrementation logic out of the ui code, allows the ui to easily repost the current mixing spec with whatever revision number the server responded with when things fail.
On Mon, Jul 21, 2008 at 3:28 PM, Randall Leeds <[EMAIL PROTECTED]> wrote: > We've seen some problems with requests coming in out of order. What makes > this problem especially ugly is that we have an implicit save going on. When > you change feeds and filters too quickly, or for any number of reasons > there's a hiccup somewhere and the requests make it into the back end out of > order, the result is that you may overwrite your newest changes. > > To fix this, I'm storing a revision key/value in the mixing spec. I'm also > making save explicit (that is, explicit in the code, not in the user > experience currently). Save will happen in a separate ajax request. The > response to this request will either be a 200 (OK), 400 (Bad request, i.e. > missing revision number) or 409 (Conflict). In either of the error cases the > front end will be receive a response with the current server-side revision > number. > > I solicit your feedback. Greatly appreciate. > > -R >
