Brett - I feel that my comments are well informed, not blinkered at all. But we will leave this conversation alone at this point as it has just become completely inappropriate.
Dan Brett Morgan wrote: > On Dec 3, 2:54 pm, Daniel Paull <[email protected]> wrote: > > I had qualified my use of the term client previously when I said, > > "When I say client, I mean client as in client/server". > > > > I liked your first post. However, to demostrate that the > > transformation is unambiguous, you need to generate [Oa, Ob'] and [Ob, > > Oa'] and show that they give the same result. > > > > There is no need to talk about the federation protocol to answer the > > question. The ambiguity that the OP talks about can only ever happen > > on the client (meaning the client that the user interacts with), so > > what the servers do amongst themselves is irrelevant. > > This blinkered refusal on your part to accept that federation is > relevent to understanding how OT works in the Wave Protocol speaks > volumes. > > > I feel this conversation is getting nit picky and off topic now. > > What I feel about this conversation is unprintable. > > > Dan > > > > Brett Morgan wrote: > > > 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 > > > > ... > > > > 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.
