On Jul 12, 10:25 am, Alex North <[email protected]> wrote: > New blips appear below old blips in the same thread; new > replies to the same piece of content appear below old ones. It's arbitrary, > but in this case we can improve the user experience by putting later content > later.
If I read just that text, then I would completely agree, especially since you keep using the word "appear". To me this is a problem of presentation, not an issue for your OT algorithms. For example, I've been mulling over a chat client that presents concurrent messages as "siblings" in an otherwise linear list of messages. This makes it clear to the user that certain messages were generated in the same context, regardless of wall-clock time. It's techniques like this that will make OT based systems intuitive and behave consistently regardless of latency (consider an offline client to be just like any other client, only it has really long latency). > Online users, not familiar with the semantics of OT, would be surprised to > see content logically inserted at the same place as some their own but > arriving later appear above it rather than below it. You see, I would put it beside it, not below it. > An exemplary case of the oddness is appending blips to a thread in Google > Wave. If two users concurrently append blips then they appear in some order > and neither user is too surprised when it all happens within the space of a > second. But if one user is temporarily offline then when they return their > blip ends up above all blips created while they were offline. This is > unexpected to everyone observing and may unintentionally change the meaning > of existing blips. You see, I would put it beside it, not below it. > This behaviour could be fixed if the conversation model was implemented > differently. As it is the structure of the conversation manifest mirrors the > logical structure of the conversation. The lists of blips that form each > thread are in top-down order and appending is modeled as as an insertion at > the end of the list > > <thread> > <blip id="first"/> > <blip id="second"/> > </thread> > > The concurrent behaviour could be fixed by reversing the order of the blips > and threads in the manifest, and that's what is meant by "last is first". I'm not sure that your proposed fix actually fixes the problem at all. Rephrase that - I'm not sure that there is actually a problem in the OT functions that needs to be fixed. > It's entirely my fault for not seeing this poor OT behaviour when designing > the structure. Let's not impart blame until we actually know that there is a problem with the OT functions. > Development and debugging is much easier > when the data matches the conceptual model. Ahhh - perhaps the conceptual model has a bug? > > The classical approach is to use the site identifier to break the > > tie. That is, there is a total order on sites and, say, the "lower" > > site goes first. > > Luckily we don't need to do that, and can instead use temporal order at the > server to provide the most natural (for humans) ordering of content. Luck or side effect. Whatever. No one else does it this way and there are good reasons for that. But we've had that argument before. To rehash, I live on the side of the fence where satisfying TP2 is actually important. If your were to implement algorithms that satisfy TP2, then the "temporal ordering at the server" simply does not exist, therefore your entire argument about what is "natural to the human" is moot. I would suggest that just because there happens to be an ordering of operations at the server, it's an abuse of OT to rely on it to give any sort of "desirable behavior". If you do, it's going to come back and bite you down the track. For example, if you ever work out how to get Wave to allow multiple servers to accept operations for a given wave, then you have no ordering of operations to hack into and a whole lot of strange behavior will emerge. > I hope that sheds some more light on the reasons we're behind this proposal. Well, yes it does, but I can't agree with you. I still maintain that the decision of which insertion point gets bumped when insertion collide is arbitrary. If you think it's not, then I think you're thinking about it wrong. Cheers, Dan -- 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.
