Thanks to you John for your very helpful posts, in particular in (15: on Feb 4): OT answers the question: "What do the A operations look like if the B operations were already applied?" this single statement will help many readers I think.
Practicalities of applying server operations In (9: Feb 3) you illustrate the OT challenge by describing many scenarios, I'd like to refer to your example where a client sends a delta as modification to v9 and since the latest version at the server is still v9, you say the server "response says (no changes, now at v10)". I know this was an illustration, but I find that the Rpc protocol cannot return ANY operations, only the number of applied operations. (I refer to the revision bebbbb612b of Dec 24, 2009 when the ProtocolSubmitResponse callback was introduced into waveclient- rpc.proto). So, in neither the "no changes" case or the general case of "some changes" do we get fed back the ops during the return from the ProtocolSubmit. The FedOne ClientBackend provides a means to subscribe to inbound update operations. These appear to be every single server operation even if operations originated by that client - let's call these "echo operations". I am experimenting with a client that allows client-side edits whilst waiting for a submit operation to return from the server. In this case I am aware I need to Transform pending outbound client operations and new inbound server operations, but what do I do with inbound echo operations? I can see that these echo operations would be useful if I was not applying my local edits to a local model, but in my case I am applying the ops to the local model as edits are made, simultaneously I generate the outbound ops. In (9: Feb 3) you make this point: "Key point 2: Any operations generated while waiting for a server response need to be tracked, because they might get transformed!" but does this idea also apply to operations that were sent in that server submission? as these operations are going to come back to the client as "echos". Those inbound echo operations are either going to be: a) semantically identical to the outbound operations the client sent (maybe with some Composition in there?) b) transformations of the outbound operations because of updates made by other clients prior the processing of the client's submission. I think I am missing some kind of cunning transformation that takes in those echo operations and nullifies them in the case of (a), and generalises so to handle (b). Or is my mistake that I should not apply desired operations to my local model as they are made - I must wait for the server to formalise these operations? If this is the case, it makes the idea of building an optimistic client quite a lot more difficult -- 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.
