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? > 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. 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? 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. 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". 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.
