Michael,
On 10/06/13 21:53, Michael MacFadden wrote:
Dave,
Thanks for your thoughts. A few things to consider. There is a
distinction between P2P messaging and P2P OT. A system could reasonable
have a client server messaging architecture where the server is a hub and
the clients are spokes. All messages from one client flow through the
server to get to other clients. However, even in this arrangement OT can
still happen in a P2P mode. If the server is simply acting as the
messaging relay and doing no OT, then the OT can happen at the clients.
Good point.
Googles Wave leverages client-server messaging AND client-server OT. That
is the server is participating in the OT. OT only happens in paris
between the client and the server.
In terms of mobile devices, unless we are talking about some form of
bluetooth or local wifi, then it is likely that messaging with be client
server. However, how OT happens is up for debate.
There are pros and cons to doing OT in a client-server or P2P manner.
ok - I guess this is the what I was really asking. What are the
advantages of doing OT in a P2P manner?
Googles view was that if you have potentially hundreds or thousands of
collaborators, then in a P2P mode you wind up with state vectors, vector
clocks, or context vectors that are just to large. Each peer has to track
the state of each other client. Operations typically have a context
vector attached to them. In this case you have context vectors, and state
tables that grow out of hand. Google chose to avoid this by using a
client server OT model.
I'm not familiar enough with Wave's code, but these sound like valid
design choices, even more so when aiming for a client on a phone or
phone like device?
I guess having the server participate in OT also seems instinctively
more natural to me, so I'm trying to get up to speed with why a
wave-like system would benefit from P2P / TP2 style OT.
I think that saying that the wave algorithm doesn't satisfy TP2 is a bit
inaccurate. I believe it does satisfy TP2 in that three clients can still
make concurrent edits to the document state. The server simply chooses to
canonically order these in order to ensure that TP2 is honored. One could
argue that the wave algorithm satisfies TP2 by never letting the situation
arise in the first place, but in my view this still satisfies the
requirement.
Perhaps my understanding of the differences between TP1 and TP2 is
incorrect? I thought TP1 resolved the three-way conflict by breaking it
down into two pairs (A+B = AB, AB+C = ABC), where TP2 also effectively
allows multiple changesets without implying order(so A+B+C = A+C+B =
C+B+A etc.).
Both allow 3 or more participants, but TP1 requires changes to be merged
one at a time, which wave implements with a canonical ordering of
changesets. TP2 removes the requirement for a canonical ordering, and
allows the changesets to be applied in any order, with a guarantee that
once all changes are merged, the final document will be the same -
irrespective of the order the changes were applied.
FYI, I have worked extensively with Wave's OT, other systems OT
algorithms, and have been working closely with the researchers who are
working OT right now. I think this is a very good discussion. One I can
bring to the larger OT community if we so desire.
~Michael
On 6/10/13 9:38 PM, "Dave" <w...@glark.co.uk> wrote:
[John B - I wasn't sure where else it would be appropriate to ask this
question, but please forward on anywhere you think it appropriate]
There are many things about Wave and WIAB that I would like to see
improved / changed, but based on my readings I've been content with the
TP1 OT approach chosen by google (not that I'm even close to an expert)
- even if the WIAB implementation would benefit from some love.
But one of the things mentioned in the recent wave-forward hangout was
the weakness in Wave's OT implementation for a required canonical
version of a given wave (providing absolute ordering of changesets).
Specifically, this effectively prevents 3 party P2P messaging where
there isn't guaranteed to be that one canonical ordering. My
understanding is that Joseph is playing with some alternative OT
algorithms that are TP2, and therefore don't require arbitration of
changeset order. This was specifically called out as an advantage to
support P2P messaging and running the full stack on a phone.
That got me thinking - why would you want to do that? What are the
benefits of P2P messaging, and are there other reasons to need TP2?
Most of the messaging and collaboration systems I could think of are
client-server (some with federated servers) and Wave/WIAB support this
with TP1. Most networked phone apps that I'm aware of are also
client/server, and at first glance this seems a good thing - it makes
addressing easier and avoids issues with intermittent connectivity. The
ability to have a simple "wavelike" server (and detached clients)
I suspect I'm missing something, and I wondered if I'm alone?
My understanding is that technical interop between the various wave-like
communities will need us to use the same OT alogrithm (eventually), so
clarity on the pros/cons of keeping or changing the wave OT approach
would be a good first step in that direction!
Dave
