An hour and a half ago, Hendrik Boom wrote: > > Two parts to this -- the editor, and a message/event/state > maintenance system. > > YOu don't actually *need* a server as long as clients can > communicate. > > Timestamp the messages in an unambiguous fashion, possibly something > like a pair (local time. client identity). Arrange to have all > messages processed sorted by such a time-stamp. Write the editor in > a functinoal style -- you know, as a mapping that takes a state and > a sequence of messages and returns a new state. When a message > arrives out of order, possibly delayed, you can replay the sequence > of edit commands from an earlier state. Both client machines can do > this imdependently. THe purpose of the unambiguous time-stamps is > to ensure that they will eventually converge on the same sequence of > edit operations.
That doesn't help -- the problem is when the two clients are not connected for a while or the connection is not fast enough, and you get two contradicting edits. The trivial solution of forcing things to be sequential mean that typing speed is limited by the network which can be impractical in many cases. (In cases where it is practical, the whole thing is even easier than that, you just need to bounce messages and make sure that both sides get to see the same sequence of edit steps.) This is also relevant: http://code.google.com/p/google-diff-match-patch/ -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! ____________________ Racket Users list: http://lists.racket-lang.org/users
