On Fri, Mar 02, 2012 at 02:39:20PM -0500, Eli Barzilay wrote:
> 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.
No. Locally, it's updated immediately, without any network delay, so
it doesn't affect typing speed. Only in the case that both users are
typing into the same place is there any confusion -- and in that case
the trouble will soon become evident, and the users will have to
communicate by other means.
> (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!