I'd resolve large (by some threshold) uncommitable changes as a new private wavelet inline at that position with an error message and the uncommitted changes and only the changer as a member of the wavelet. The user can then keep their changes, apply them somehow (new blip, etc. as they choose) but we guaruntee that the action is permissible for the user (private replies are always possible, regardless of the permission model; at least initially).
~ Doug. On Dec 1, 10:33 pm, Tad Glines <[email protected]> wrote: > 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.
