Hi Dan, On Fri, Jan 22, 2010 at 12:53 AM, Daniel Paull <[email protected]> wrote: > 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.
Fair enough. It was intended to address some of your earlier comments about the lack of thorough documentation of our client/server protocol and the lack of an open-sourced version of the client/server protocol that our browser clients use. > >> 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. The decision to not use the client-generated ID was made for pragmatic reasons. At the time we decided the overhead of including the unique-id in all messages sent by a client, broadcast by the server to all listening clients and including it in persistent storage was a larger penalty than a comparison on the client. We are considering adding a unique id back for other reasons (e.g. something analogous to the history hash used in the federation protocol), so it might well make a reappearance. Our client/server protocol is based on the Jupiter paper, and we do have the concept of a vector-time, however we don't always use the same language when communicating informally. We have added features to the basic OT algorithm to make the implementation of a client/server protocol simpler and/or more performant. Because we have not finalized the client/server protocol, we have not published or open sourced it yet. We are working on doing this. We're happy to discuss the choices we made and adjust the protocol when it becomes part of the other efforts for a standardization process. Given the tight constraints on our time, we have prioritized work on the federation protocol (over the client/server protocol), but we are also working on open sourcing the client/server protocol. Apologies if our time constraints are causing frustration, we too would like to make faster progress. regards, Jochen -- 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.
