Re: load time regression: Re: commit: Change Record UUID's

On Tue, 2005-10-25 at 00:46 +1000, msevior@physics.unimelb.edu.au wrote:
>
> I'm not so sure about that. I think that after synchronization we actually
> do want counters running on each users document. The counters will inform
> other members of the abicollab network if there has been a clash of edits
> due to network latency.
>
> ie if Alice and Bob are both editting the same document then there was no
> latency issues something like this would happen:
>
> Alice Bob
> counter Counter
> 1 1 (initially)
> 2 1 (Alice edits)
> 2 > 2 (Alice's edit is tranmitted to Bob and is applied)
> 3 2 (Alice edits again)
> 3 > 3 (Transmitted to Bob)
> 3 4 (Bob edits)
> 4 < 4 (Transmitted to Alice)
> 4 5 (Bob Edits again)
> 5 < 5 (Transmitted to Alice)
> 6 5 (Alice edits)
> 6 > 6 (Transmitted to Bob)
>
> OK Now suppose we have a latency issue....
>
> 7 7 (Alice and Bob both edit before seeing the other)
> 7? <> 7? (When the packets arrive they see counters equal
> or greater than themselves. So they know they need
> to do some sort of conflict resolution.)
>
> I talk about how to solve this sort of problem in the GOCollab document.
>
The documents that I sent around before discuss using a vector time
stamp where there is a counter for each "site" aka each instance of
abiword. There is a famous paper here from a MS research guy detailing
it, unfortunately I don't understand it well enough to explain it fully.

http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf

I think we can avoid using the system clock in order to get GOCollab to
work.

-Matt