Want suggestion on implementing collaborative repls and alikes

Want suggestion on implementing collaborative repls and alikes

[Qiantan Hong]

Copied from a communication with my friends:

> Still, I haven’t done the work to make crdt.el work with
> xscheme.el and alike yet.
> In fact, I haven’t decide on the following two implementation strategy,
> and the choice *will affect UI behavior*:
> 
> 1) Proxy at command level: 
> When client invoke C-x C-e and alike, send the invoked Emacs command 
> directly to the server.
> 
> This strategy is easy to implement, but there’re hypothetically
> some issue during concurrent edit. E.g. user A might see
> (+ 1 1) in their buffer, and press C-x C-e.
> However, when the “C-x C-e” message arrives at the server, some
> other user might have changed it to (+ 1 1 1).
> The server will then just execute what’s in its buffer at the time
> of receiving the message, and writes ;Value 3
> 
> 2) Proxy at buffer process and buffer local variable level.
> The client execute the whole C-x C-e command locally, only
> when the code try to send to buffer process (which only exist on server)
> or modify some variables annotated to be synchronized,
> such operation are intercepted and sent to the server.
> 
> This doesn’t has the problem of 1, but is much more complicated
> and require adding lots of annotation in xscheme.el etc to work.
> Moreover, it’s hard to figure out the correct annotations to make
> the synchronization really correct.
> (1 doesn’t have this issue because we know it’s always incorrect! 
> but maybe not so incorrect to be unusable).

More detailed in HACKING.org on the development branch of crdt.el
under "Why we need used-state-set annotations”.
(web url https://code.librehq.com/qhong/crdt.el/-/blob/development/HACKING.org)
It writes about a way to resolve user intention problem for command-level strategy,
but add more complexity to this simple approach:
> The correct solution is to let the server roll-back to the state when Ben Bitdiddle invoked the command.
> It is relatively expensive thus we don't want to do this for every command,
> thus we require package hackers to annotate explicitly.
> 
> /The above mechanism haven't been implemented yet!/ 
> But adding annotations now will help adding it in the future.
> To implement this mechanism we need to add lamport timestamp to every messages 
> (which may corresponds to mutation of interesting states),
> and send a vector clock in =command= messages which depend on buffer content.

Many REPL like modes depends on the above strategies,
e.g. shell-mode eshell-mode and other comint-mode derivatives.

Any thoughts on which way to go? How far should we go?


Best,
Qiantan