On Dec 3, 12:42 pm, Daniel Paull <[email protected]> wrote: > Brett - let's just take a step back here. All this conversation is to > answer this question: > > "On the server a piece of text is lets say "15" and two clients alter > the same piece in "16" and "17" respectively. What would be the > outcome of the transforms? There is no unambigeous way to cope with > this edit I think."
I showed that there is an unambiguous way to cope with that scenario when I posted code using wave's BufferedDocOps, Composer and Transformer. > There is no need to talk about federated servers to answer the > question. I disagree, as server federation uses this code extensively in dealing with the above scenario, amongst others. > The FedOne client, to my understanding of where it is at now, does not > wait for acknowledgements from the server (nor does the server send > acknowledgements to clients) and does not perform any OT. It is a > completely differnent animal that what is described in the Google OT > white paper and is not, at this stage, a sensible reference for anyone > trying to understand how to implement a Wave client or understand how > clients/servers interact. Am I wrong with my understanding of where > the FedOne client is at? Again, you are using the term client without qualification. I told you there are two separate client/server relationships in the FedOne code base, yet you continue to talk as if there is only one. > Dan > > Brett Morgan wrote: > > The problem here is that there are two separate client/server > > relationships. > > > Firstly there is a client/server relationship amongst the federated > > servers, where in the server that is hosting the document acts as a > > server to the relying federated wave servers that act as clients. > > > Secondly, there is a client/server relationship between a wave server > > and it's ui clients, be they web applications or otherwise. > > > Yes, the client server terminology has been overloaded with the need > > to understand the context of the communication in question. This is > > unfortunate, but it is a natural result of the complexities of > > building a real system. Real systems are not the simple things they > > write about in academic papers. Here in the real world we have to deal > > with the very real physical limitations of things like hard disks and > > routers. > > > The reason I am talking about the federation protocol is that it is a > > real example of a client server protocol that uses OT. It can be used > > to inform the discussion of how web clients could interact with their > > wave server using OT. > > > Stating that FedOne doesn't implement a sensible client/server > > protocol at this point is incorrect. > > > On Dec 3, 11:19 am, Daniel Paull <[email protected]> wrote: > > > When I say client, I mean client as in client/server. I dislike the > > > overloading of the word client that has been used in this thread and > > > it has caused much confusion, and I am sure, misinterpretation. In > > > what way is an upstream or downstream wave provider a "client"? They > > > should be described as caches and proxies respectively. > > > > I also don't understand why the federation protocol is being discussed > > > here as the OP was asking about how concurrent operations from two > > > clients are handled when the transform clearly results in an > > > ambiguity. > > > > I also don't understand all the references to the FedOne code base as > > > FedOne does not implement anything the remotely resembles a sensible > > > client/server protocol at this point in time. > > > > Dan > > > > On Dec 2, 12:40 pm, Brett Morgan <[email protected]> wrote: > > > > > I just want to clarify here that by "client", you are talking about > > > > the remote wave servers, not the traditional usage of the term client, > > > > for example of web client that displays content from a wave server. > > > > > The many uses of the term client in this context are going to lead to > > > > people becoming confused if we are not careful. > > > > > On Dec 2, 3:35 pm, Daniel Paull <[email protected]> wrote: > > > > > > The FedOne source does not implement server acknowledgements, nor does > > > > > the FedOne example client perform any OT, so reading the FedOne source > > > > > is not going to help at all. The only information that exists at this > > > > > point in time on how the client and server interact is in the Google > > > > > OT white paper. > > > > > > Dan > > > > > > Brett Morgan wrote: > > > > > > Dan, > > > > > > > The basis of this is already in the published FedOne source. You > > > > > > could > > > > > > check what they have done instead of trying to figure out what they > > > > > > should have done. > > > > > > > brett > > > > > > > On Dec 2, 2:19 pm, Daniel Paull <[email protected]> wrote: > > > > > > > Oops - forgot the important bit! The Google OT White paper > > > > > > > states: > > > > > > > > "When a server acknowledges a client's operation, it means the > > > > > > > server > > > > > > > has transformed the client's operation, applied it to the server's > > > > > > > copy of the Wavelet and broadcasted the transformed operation to > > > > > > > all > > > > > > > other connected clients." > > > > > > > > So, unless that is in error, transofrmed operations are sent from > > > > > > > the > > > > > > > server to the clients. > > > > > > > > It seems crazy to send to original, untransformed operation to the > > > > > > > clients as the clients will have to repeat the transformation work > > > > > > > that the server has already done! > > > > > > > > Dan > > > > > > > > Daniel Paull wrote: > > > > > > > > Hi Tad, > > > > > > > > > What you have written here is more in line with what I > > > > > > > > understood of > > > > > > > > the federation protocal where servers act merely as proxies and > > > > > > > > caches > > > > > > > > for Waves that they do not own. So all servers should end up > > > > > > > > with the > > > > > > > > same state space as you have indicated. > > > > > > > > > As you note, this does still leave the question unanswerd - > > > > > > > > what does > > > > > > > > Google do in their wave client? The recently released Python > > > > > > > > Wave > > > > > > > > client code also offers no clues as there is presently a bunch > > > > > > > > of > > > > > > > > "TBD" markers in the code where the client would perfrom OT. > > > > > > > > > One thing that is clear is that clients will apply operations is > > > > > > > > different orders, so TP1 must be met. It will be interesting > > > > > > > > to see > > > > > > > > what the community comes up with on the client side as it is > > > > > > > > much more > > > > > > > > complex than what the server has to do. I wonder how long it > > > > > > > > will > > > > > > > > take before a correct implementation is developed! > > > > > > > > > Cheers, > > > > > > > > > Dan > > > > > > > > > Tad Glines wrote: > > > > > > > > > I see the problem here. You think I'm still talking about > > > > > > > > > site identifiers. > > > > > > > > > > My very first reply was about site identifiers. And we both > > > > > > > > > ended up > > > > > > > > > being correct. I was correct in that wave OT doesn't use > > > > > > > > > explicit site > > > > > > > > > identifiers. You where correct in that wave OT probably uses > > > > > > > > > "implied" > > > > > > > > > site identifiers (client and server). > > > > > > > > > > I then read your blog in which you state that the server sends > > > > > > > > > transformed deltas to the client. My subsequent posts mostly > > > > > > > > > focused > > > > > > > > > on the fact that the server doesn't send transformed deltas > > > > > > > > > (we'll > > > > > > > > > ignore the "toy" client). Your blog is very well written and > > > > > > > > > gives a > > > > > > > > > good detailed description of how OT works. The only > > > > > > > > > discrepancy is > > > > > > > > > that the server doesn't send transformed delta's to the client > > > > > > > > > (federation remote). It sends the original un-transformed > > > > > > > > > delta. > > > > > > > > > > I just did another review of the FedOne code and cleared up > > > > > > > > > another > > > > > > > > > assumption I had made. The federation remote doesn't do OT > > > > > > > > > the way we > > > > > > > > > had assumed. When a delta originates from the remote > > > > > > > > > (client), the > > > > > > > > > delta passes through the remote (without OT) and is sent to > > > > > > > > > the host. > > > > > > > > > > If we start with: > > > > > > > > > > Host [O1, O2, O3] > > > > > > > > > Remote1 [O1, O2, O3] > > > > > > > > > Remote2 [O1, O2] > > > > > > > > > > where: > > > > > > > > > > Remote1 has sent Oa > > > > > > > > > Remote2 has sent Ob > > > > > > > > > > When Host gets Oa it will not do OT and will apply it > > > > > > > > > directly then > > > > > > > > > send it to Remote1 and Remote2. > > > > > > > > > When Host gets Ob it will transform it against O3 and Oa then > > > > > > > > > send Ob > > > > > > > > > to Remote1 and Remote2. > > > > > > > > > > When Remote2 gets Oa it will notice that it is missing O3 and > > > > > > > > > will > > > > > > > > > request it from the Host. Regardless of the order in which > > > > > > > > > O3, Oa and > > > > > > > > > Ob arrive, Remote2 will optionally transform and apply them > > > > > > > > > in the > > > > > > > > > order specified in the "applied_at" version of each delta. In > > > > > > > > > this > > > > > > > > > example, O3 and Oa will be applied with out transformation > > > > > > > > > and Ob will > > > > > > > > > be transformed against O3 and Oa before being applied. > > > > > > > > > > If Remote1 gets Ob first it will store it and wait for Oa > > > > > > > > > before > > > > > > > > > applying Oa, transforming Ob against O3 and Oa and then > > > > > > > > > applying Ob'. > > > > > > > > > > The resulting state space is: > > > > > > > > > > Host [O1, O2, O3, Oa, Ob'] > > > > > > > > > Remote1 [O1, O2, O3, Oa, Ob'] > > > > > > > > > Remote2 [O1, O2, O3, Oa, Ob'] > > > > > > > > > > This still leave the question of how Google handles OT in > > > > > > > > > their client. > > > > > > > > > > -Tad > > > > > > > > > > On Tue, Dec 1, 2009 at 5:26 PM, Daniel Paull > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > Hello Tad, > > > > > > > > > > > Following what you just wrote: > > > > > > > > > > > Remote1 will end up with [O1, O2, O3, Oa, Ob'], where Ob' > > > > > > > > > > is IT( Ob, > > > > > > > > > > Oa ), and, > > > > > > > > > > Remote2 will end up with [O1, O2, O3, Ob, Oa'], where Oa' > > > > > > > > > > is IT( Oa, > > > > > > > > > > Ob ) > > > > > > > > > > > So, as per my previous message, for Remote1 and Remote2 to > > > > > > > > > > converge to > > > > > > > > > > the same document state, then [Oa, Ob'] must have the same > > > > > > > > > > effect as > > > > > > > > > > [Ob, Oa']. Note that this is exactly what TP1 states. > > > > > > > > > > > Please explain how convergence is possible without > > > > > > > > > > resorting to site > > > > > > > > > > identifiers (either explicit or implied) in the case of > > > > > > > > > > inserts at the > > > > > > > > > > same position, as per > > ... > > read more » -- 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.
