Heheheh, yeah. For better or worse, people prefer web applications to desktop applications.
brett On Thu, Feb 4, 2010 at 2:31 PM, Daniel Paull <[email protected]> wrote: > Thank you Brett for pointing out the mismatch of most Web technologies > to Operational Transform - or any other message passing protocol for > that matter. But, you just go ahead banging that square peg into a > round hole. You'll get it to fit eventually. > > Cheers, > > Dan > > On Feb 4, 8:41 am, Brett Morgan <[email protected]> wrote: > > On Wed, Feb 3, 2010 at 11:19 PM, Daniel Paull <[email protected]> > wrote: > > > hi John, > > > > > That's an excellent description of what goes on between clients and > > > servers when there are concurrent edits. It's a great starting point > > > for forming a picture in your mind. > > > > > There are probably a few details that aren't quite right - but that > > > may be because there is no standard way that the client and server > > > communicate and e are all confused because of this! For example, you > > > said, "Client A sends an empty delta to ping the server ([...@v8) and > > > gets a response of [B1',B2',B3',B4',B5'], now at v10)." This is not > > > how it should work. The server is able to send updates to the clients > > > at any time rather than clients polling the server for updates. The > > > OT whitepaper talks about a broadcast of transformed operations to > > > clients. This broadcast must happen before the acknowledgement is > > > sent back to the originating client. > > > > Dan, > > > > If the client in question is a web client, and we aren't using WebSocket > or > > a hack like long polling, then no, the server can't send updates to the > > clients when ever it feels like it. This is especially true when dealing > > with a back end system like AppEngine... > > > > brett > > > > > > > > > > > > > Cheer, > > > > > Dan > > > > > On Feb 3, 6:37 pm, John Barstow <[email protected]> wrote: > > > > On Wed, Feb 3, 2010 at 4:44 PM, Turner <[email protected]> > wrote: > > > > > Hi John, > > > > > > > Is that correct? If so, I'm a little confused about how the clients > > > > > deal with this. For example, client A has applied A1, A2 and A3, > and > > > > > gets back streamA' from the server (right?). But it can't just > apply > > > > > B1-3', can it? I haven't worked it out, but I don't believe that > that > > > > > would work. Does client A hold off on "committing" its changes to > its > > > > > own content until it gets the up-to-date version from the server > > > > > (whether compressed by the Composer or not)? > > > > > > Here's how I explain it; note that I'm working off memory at the > > > > moment so someone might have to correct me. > > > > > > At startup, clients A and B get the latest version from the server. > > > > Let's be arbitrary and say we start at v7. So the server and both > > > > clients are synced at v7. > > > > > > Key point 1: The "last known version" is how the server knows what > > > > needs to be transformed! It's sent as part of every delta. > > > > > > Client A generates some operations. Let's say [A1, A2, A3]. It sends > a > > > > delta to the server containing the operations and the last version it > > > > knows about. ([A1,A2,a...@v7) > > > > > > Server sees the delta from client A, sees that it's still at v7, so > > > > just commits the delta as v8. It sends back a response that > > > > essentially says (no changes, now at v8). > > > > > > Client A has no outstanding edits, so it just bumps the "last known > > > > version" variable internally. > > > > > > Client B generates [B1, B2, B3] and sends a delta ([B1, B2, b...@v7). > > > > While waiting for a response, it generates [B4, B5]. > > > > > > Key point 2: Any operations generated while waiting for a server > > > > response need to be tracked, because they might get transformed! > > > > > > Server sees the delta from client B, and that there is a newer > > > > version. So it takes all the operations committed since v7 and > > > > transforms them. > > > > > > [A1, A2, A3] x [B1, B2, B3] = [A1', A2', A3'], [B1', B2', B3'] > > > > > > The B' operations get saved as v9. The server generates a response > > > > saying ([A1',A2', A3'], now at v9). > > > > > > Client B now needs to apply the changes returned by the server, but > it > > > > has some pending operations. That means it needs to apply a > transform. > > > > > > [A1', A2', A3'] x [B4, B5] = [A1", A2", A3"], [B4', B5']. Client B > > > > applies the A" operations and bumps the "last known version" to v9. > > > > The [B4', B5'] can now be sent to the server as a delta ([B4', > > > > B5']...@v9). > > > > > > Since v9 is that latest version, the server applies the delta as v10. > > > > The response says (no changes, now at v10). Client B has no more > > > > pending operations, so it just bumps the "last known version" to v10. > > > > > > Client A sends an empty delta to ping the server ([...@v8) and gets a > > > > response of ([B1',B2',B3',B4',B5'], now at v10). > > > > > > Since Client A has no pending operations, it applies the delta as-is > > > > and bumps the "last known version" to v10. > > > > > > We're done, now the server and both clients are synced at v10, even > > > > though all three applied different sets of operations! > > > > > > Anyplace you have a sequence of operations bundled up - anywhere I've > > > > used [ ] brackets - you can optionally do a compose to reduce the > > > > length of the sequence. > > > > > > I hope that makes sense! Tracing that out was the main thing I did to > > > > get my head around the algorithm. > > > > > -- > > > 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]<wave-protocol%[email protected]> > <wave-protocol%2bunsubscr...@goog legroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/wave-protocol?hl=en. > > > > -- > > Brett Morganhttp://domesticmouse.livejournal.com/ > > -- > 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]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- Brett Morgan http://domesticmouse.livejournal.com/ -- 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.
