On Jul 5, 2:52 pm, Alex North <[email protected]> wrote: > Hi all, > > We've just published some proposals for significant changes and > improvements to the Google Wave protocols and models. You can find them on > the Wave Protocol website athttp://www.waveprotocol.org/design-proposals. > > These particular proposals were drafted as internal design documents > earlier in the year, but we have not yet found the time to implement these > changes. As part of the effort to do more work in the open source > community, > we're publishing these documents for your comments and to provide > transparency about the future direction of the protocols. > > In general, most significant changes to the protocol and models begin > with such a document and we aim to publish ones for future improvements > too. > > Cheers, > > Alex
Hi Alex, Regarding the "OT insertion order design proposal", I do not see why this change would be necessary. Perhaps I'm tainted by having worked with more general OT algorithms, but the order that results from concurrent inserts at the same location is arbitrary - the only requirement is that all sites need to agree on which order is chosen. The proposal states, "The last-is-first interpretation means data structures need to be represented "backwards" in the document to have desired transform. To create a list, appending to the list would be implemented as inserting at position zero, like a stack." I don't understand this at all. If I were building up a list by generating insert operations at position zero, I should see the most recently inserted item at position zero, not at the end of the list as you claim. This is because subsequent operations are generated in the context of previous operations, and as such, they are not be considered concurrent and there is no collision of insertion points (this is basic causal order stuff). Perhaps your example was alluding to building a list of n elements by carefully coordinating the insertions of n wave clients such that all operations are generated concurrently, but arrive at the server in a predetermined order? That's a pretty strange case to be concerned about. I don't see why two users who both have operations that insert at the same position "in flight" at the same time are surprised to see the resulting inserts performed one order or the other. The proposal states, "Currently, when offline or flaky clients come back online, their new content is inserted before content that online clients already submitted to the server. With a change, the content comes after content which reached the server first." My first though was, so what? Why is it desirable for "offline work" to come after the other operations? The proposal seems to be trying to imply some sort of temporal order to the concurrent operations - "later" inserts appear "after" earlier inserts. In the case of the offline work, there is a good chance that the offline work was performed, in wall- clock time, before the operations received by the server while the client was offline. Shouldn't the offline client therefore go first? The proposal states, "With a change, other people's carets, as seen in your editor, are more representative of where in-flight characters will actually arrive." Have you considered that maybe the problem is with the caret handling? You'll need to explain this problem in more detail. 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. So, my reaction to the proposal is threefold: 1) In my mind, the decision of "who goes first" when concurrent inserts collide is arbitrary in the current Wave OT implementation, so just leave it like it is. 2) In my mind, the decision of "who goes first" when concurrent inserts collide should not be arbitrary - a total ordering on sites should be used to decide who goes first. 3) If you were to entertain the idea of satisfying TP2 at some point, then you there is no decision to be made as there is no "order that operations arrived at the server" that can be used. 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.
