> > > > 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. >
Cool. I've yet to encounter an asynchronous multi-master replication system that was 100% or mostly conflict free. I hope you succeed. 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. > I see the confusion now. My original response to David's point number 2 was based on the incorrect assumption that a TP2 system would not have the ability to regain lost state. If a system needed reliably exchange messages, then my comments about TCP and the need for application level acks are correct. However my comments don't apply to a TP2 system. > > > > 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. > I still think that branching and merging can be done with the existing Wave OT. But I'm not certain yet, so I'll hold off on further comment until I've had a chance to do some testing. -Tad -- 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.
