You shouldn;t be mystified by what I have said - the FedOne client (yes, the console client) is not a Wave client as described in the Wave OT white paper from Google. In my opinion, Google has caused much confusion by providing a client that bears little resemblance to what they have documented as a proper Wave client.
For example, you said "With the FedOne console client, TCP acknowledgement seems like the only acknowledgement you'll get from the server." Right - this is what is broken. You can't implement a proper FedOne wave client because the FedOne server does not act like a proper Wave server. If it did, the question asked that started this discussion would most likely not have been asked! My answer to the original question is "implement server acknowledgements as documented in the Google OT whitepaper and the problem no longer exists." I find comments like "The server does not broadcast to clients that do not do OT, correct me if I'm wrong" very confusing. Wave clients perform OT. If they don't, they're not a Wave client - they are something else entirely. Cheers, Dan On Jan 20, 10:19 pm, chiang <[email protected]> wrote: > Hi Dan, > > I must admit that I'm a bit mystified to see you keep calling the > client (presumably you are referring to the FedOne console client) > broken :) when the client does not do OT, which is probably why it > does not seem to follow what the Google OT white papers says. > > Please see comments inline: > > On Jan 20, 1:10 pm, Daniel Paull <[email protected]> wrote:> Come on, it's > broken. Maybe I can find a contrived example to > > illustrate: > > > 1) There are two clients that both have the the same, empty wave open. > > 2) Client1 generates O1 and sends it to the server. > > 3) Client2 generates OA and sends it to the server. O1 and OA happen > > to be identical. > > 4) Client1 generates O2 and caches it, waiting for the server to > > acknowledge O1 before sending O2. > > With the FedOne console client, TCP acknowledgement seems like the > only acknowledgement you'll get from the server.> 5) The server decides to > apply the two concurrent operations in the > > order OA then O1. So, it applies OA after transforming it (the > > transformation happens to be a no-op at this stage) and broadcasts OA > > to all clients. > > The server does not broadcast to clients that do not do OT, correct me > if I'm wrong.> 6) Client1 receives OA, compares it to its unacknowledged > operation, > > O1. They are the same, so Client1 incorrectly assumes that the server > > has acknowledged O1. > > If you are assuming that the client does OT here, I think each OT > operation needs to be digitally signed (to come from whatever user/ > domain). So that may resolve the ambiguity?> 7) Client1 sends OA to the > server and we all go to hell in a hand > > basket as the server is not expecting Client1 to send operations at > > this time. > > Again that can be resolved by OT? > > I'm trying to understand what is lacking in the client and what needs > to be done too. > > cheers, > > Chiang
-- 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.
