On Mon, Nov 29, 2010 at 7:27 AM, Torben Weis <[email protected]> wrote:
> I fear it is not so easy on the client side, because a client can do > everything right (i.e. edit a blip) and concurrently this blip becomes > locked by its owner. > The client receives an error message although it did not do anything wrong, > The first thing required is an error code that tells what happend. > Currently there is only a string. > But far more complicated is the following: The client may have queued > further deltas. If the in-flight delta is rejected, how to transform the > consecutive queued deltas? > I'm not sure about the concurrency control code in WiaB, but the stuff I implemented last year was able to transform the pending ops against the rejected delta. > My guess is that no client currently handles this in a reasonable way and > therefore this is a rather major change. > Correct. My stuff didn't handle it in an idea manor from the user's point of view. The user would see their changes disappear with no explanation why. > Currently we have three classes of errors > a) Transport. Solution: try again > b) Request is somehow malformed -> client is buggy. Solution: give up, send > a bug report to the developer > c) Permission denied -> user is (no longer?) allowed to change the wavelet. > Solution: drop the delta and all consecutive queued deltas. Rewind the UI. > > If a client sends a delta for a locked blip that has not been locked when > the client created the delta, then we have a new error case. > Of course we could go with c) and rewind. But imagine a user worked > offline, did tons of changes resulting in a set of queued deltas. The first > delta yields this new kind of error and all the work done offline is > suddenly reverted and gone. Not very nice! > > An intermediate solution to the whole race condition problem is to require that if a blip is to be locked, it must be created lock, and can subsequently only be unlocked, but not re-locked. From a UI point of view, there would be a lock icon or lock check-box that appears in the blip during creation/editing if the wavelet supports blip locking and the user has permission to create locked blips. Then the initial lock state of the a blip during creation would be a user preference. -Tad -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
