[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Want suggestion on implementing collaborative repls and alikes
From: |
Qiantan Hong |
Subject: |
Want suggestion on implementing collaborative repls and alikes |
Date: |
Mon, 6 Sep 2021 01:41:27 +0000 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Want suggestion on implementing collaborative repls and alikes,
Qiantan Hong <=