Hello Jochen, I understand that the Wave team is spread thin - as we all are and always will be. But that seems irrelevant with respect to my comments.
> This is the approach we currently take (as > opposed to the unique ID approach), but there is a corner case problem > as pointed out here earlier, that two clients where the same user has > logged on submit changes at exactly the same place at the same time > when a connection drops. Can you outline why you would prefer to do an expensive comparison of operations and introduce this "corner case" rather than simply utilise an identifier for the client process (I will call this a "site" from here on)? I can't say that I have ever seen this approach (comparing operation) taken in the literature. The usual approach is to identify the site generating operations. An operation can be identified by an (s, t) pair, where s is the site and t is sequence number of the operation. Why would you diverge from this? A vector-time (which is a vector of these (s, t) pairs) identifies a version of a document. In the case of wave, the vector-time for a given session will only have two entries as there are only two sites involved in the exchange of operations - the client and server. Indeed, one of the diagrams in the Wave OT whitepaper notes the "state space" as pairs of integers - this is a vector-time (the site identifiers are implied). Now, recovery *should* be a simple matter of exchanging vector-times and sending operations that you have that the other site does not. Once you are at the same version, recovery is complete. Now, there is some complexity introduced by the addition of the server acknowledgements, but I think this is merely an issue for the client - it just needs to exclude operations that it has not sent to the server in its vector-time during the handshaking. Let me harp on for a minute - it urks my that the white paper alludes to the proper use of sequence numbers and vector times, but in reality, even the Google client/server protocol does not take this approach. This does not inspire confidence. > There is a call to be made about > intention-preservation when resolving conflicts under OT, I really don't see how any of this relates to intention preservation. > If you can propose a much better solution in to > the problem discussed above, or any other, the open sourced protocol > we contribute could benefit from it (particularly if there is a > working implementation). Perhaps you should read the Google Wave OT paper as it seems to suggest a "much better solution". I would like to see an approach that builds on the current literature (such as talking about vector times, sequence numbers and site identifiers) rather than blazing inefficient trails that introduce "corner cases" for no good reason. 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.
