I still would like to know the details of actual implementation. Some kind of design doc that precedes actual coding would be very nice, that would allow the community to take part in the low level design. Or even to take part in actual coding.
One more thing that I want to talk about is the whole concept of public/private wavelets. The current default wavelet mode is "private", i.e. only participants can have access. How about changing the default mode to "public"? So, every wavelet is public until stated otherwise? I think it makes a lot more sense for a collaboration platform to be public by default. On Dec 2, 5:44 am, dougx <[email protected]> wrote: > 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.
