On Feb 27, 3:10 am, Tad Glines <[email protected]> wrote: > > 2) Simpler protocol as there is none of this sever ack guff > > > > Server's will still need to communicate successful receipt of deltas. > > > The TCP ACK is sufficient though. > > No, it's not. Just because a TCP packet has been ACK'ed does NOT mean that > the application has actually read the data out of the TCP recieve buffer. > Not does it mean that the application has finished parsing the message and > reliably done anything with it.
I'm implementing a distributed database platform that meets TP2, and have no requirement for one machine to know when another machine has read and processed a message. It sounds like you're suggesting a system satisfying TP2 requires something that resembles a distributed transaction. It's not even necessary for locally generated operations to be made durable (i.e. flushed to secondary storage) before they are sent to peers. > > > 6) Branching and merging of data in an arbitrary manner > > > > Branching and merging is still possible without TP2. > > > No it's not. You're turn. > > Perhaps we are thinking of two different things here, but, as fas as I can > tell, it is already possible to branch the history of a wavelet, and then > merge changes from one branch to another. I plan to test this, but it's not > at the top of my task list right now. TP2 is a sufficient condition to ensure convergence in the general case - i.e. when both: a) there are 3 branches or more; and b) there is no constraint on the order in which (pairs of) branches are merged. If you want to build something analogous to a source code repository such as SubVersion then you really need to support TP2. End users won't accept constraints on the number of branches or the order of merging. IMO this is the biggest limitation with the Wave Protocol. It supports real time collaboration but only a restricted form of working in isolation. The protocol ensures there is a single branch on the server by forcing clients to "update" between each "commit" (by waiting for a server ACK before the next send), which is analogous to SubVersion which may prevent a client from committing changes to a branch until after it retrieves and merges all updates from that branch. In both cases the server does this to ensure that a branch remains linear. An important difference is that Wave only allows for a single branch on the server, and the only practical way to overcome that limitation is to satisfy TP2. I think this is a problem because users don't always want to merge everything onto a single branch. Indeed for that reason source code repositories generally support multiple branches that may never end up being merged. -- 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.
