On Mon, Feb 1, 2010 at 6:15 PM, Daniel Paull <[email protected]> wrote: > On Feb 1, 11:00 am, Jochen Bekmann <[email protected]> wrote: >> Apologies if our time constraints are causing frustration, we too would like >> to >> make faster progress. > > Your time and effort is not my concern at all - never was and never > will be. Correctness is certainly a concern of mine. I don't like > that you are happy to promote a solution that, by your own > acknowledgement, is incorrect under the guise of "being pragmatic". > > Your OT algorithms, both the transformation and control algorithms > MUST be correct. If they are not, Wave will fail. By following the > Jupiter approach, you can be assured of correctness, but then you go > and get all "pragmatic" and introduce problems for no good reason. > >> 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. > > The penalty for taking your approach was to compromise correctness. > Even the most pragmatic pragmatist would have seen that as a larger > penalty than a bit of network and disk overhead... > >> We are considering adding a unique id back for other reasons > > Reasons of correctness perhaps?
Sure. > I am still riddled with confusion though - I have stated a number of > times in this forum, and even on my blog (http:// > www.thinkbottomup.com.au/site/blog/Google_Wave_Operational_Transform_and_Server_Acknowledgments) > that there is no reason for the server to send the transformed > operation back to the originating host during the broadcast of the > operation. Why do you do this? It is redundant and confusing. > Interestingly, if you did not send the transformed operation back to > the originating client, then you would not be able to do your > comparison of operations. This would have forced you to think through > the problem more carefully. > > You said previously, "Note that under normal conditions we don't echo > the entire delta back to the client in order to cut down the amount of > data on the network". For what reason do you send anything back to > the client other than the ACK? In our current implementation, the server does normally not echo transformed operations back to a client. Under some failure conditions, however, this can happen. > So, back to the original question. What do you do after a TCP > connection between the client and server is broken. The answer is > simple - you reopen the wave. As part of opening a wave, the client > and server should merely exchange vector times, indicating which > operations they have. Missing operations are sent from client to > server and vice versa so that client and server arrive at the same > state; then it's business as usual. This strategy works for opening > new waves (initial client vector time is zero), reconnecting after a > network failure, reconnecting after working offline and even when > connecting using a wave that was persisted on the client side. I see > no need for "recovery" to exist as a concept. Less is more once > again. What you just described is what we call "recovery". We do have a slightly more complex recovery mechanism to deal with a badly crashed server loosing some state. > > Having said that, upon reopening a wave there is the added complexity > that the client needs to deal with operations that it had never sent > to the server; I *think* it just needs to exclude them from its vector > time when opening the wave, but I've not proven this yet. That's due > to your additions to make the client/server protocol more "simple". On reconnection, the client offers its vector to the server, which indicates the latest of the client states it recognizes and any ops the client missed. The client resends any unsubmitted ops, if necessary first transforming them against any server ops it missed. >> We have added features to >> the basic OT algorithm to make the implementation of a client/server >> protocol simpler and/or more performant. > > Are you sure about that? The client seems to be significantly more > complex than it is in the Jupiter system. Sometimes less is more, so > be careful when adding features to something that is simple, elegant > and proven to be correct. In one or two cases our implementation is simpler, however while building our solution, there were instances where we chose a less simple option to make the overall system more performant. We were fortunate enough to be able to consult with Dixon and Lamping (http://portal.acm.org/citation.cfm?doid=215585.215706) during this process. Our current implementation may turn out not to be the best, and it may evolve to become simpler, maybe with contributions from the community after open sourcing? Fortunately, the federation protocol frees implementors to write their own take on the client/server protocol as well. 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.
