emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question collaborative editing.


From: Ergus
Subject: Re: Question collaborative editing.
Date: Tue, 29 Sep 2020 23:58:49 +0200

On Tue, Sep 29, 2020 at 12:35:54PM -0500, Karl Fogel wrote:
On 29 Sep 2020, Ergus wrote:
1) On one hand such services require some servers (to work like google
spreadsheet) and need to be provided somehow... something difficult as I
don't think gnu or fsf have resources to maintain a service like that
and provide it.

2) On the other hand it will be better if the service is somehow
distributed in order to give more privacy-security but also to reduce
the load of the servers... I still can't find any infrastructure we can
use, cause most of the peer-to-peer libraries are for C++, javascript,
Node.js and so on (example: webrtc). Just on yesterday I found
n2n... But I am not a web specialist so it requires a lot of
experimenting time for me.

3) The other workflow (create a local server for others) is the
"simplest" approach at the moment. But that is a problem for many use
cases due to dynamic ip addreses, firewalls, opening ports and so on. It
is fine for a class room or company, but not for working from home.

It's okay if a central server is required, as long as it's free software.  In practice, 
there would be a few "well-known" central servers that people use (the way many 
people just use https://pad.riseup.net/ for Etherpad today).  One of those well-known 
servers can even be set as the default in the client code in Emacs.  If some people want 
to use a different server instance to collaborate, all they have to do is set that 
variable, or specify the server through some interactive prompt.

This doesn't necessarily imply OT instead of CRDT or vice-versa.  Still, despite the 
"CRDTs are the future" message at 
https://josephg.com/blog/crdts-are-the-future/, I suspect that for Emacs's purposes OT 
might be the better solution: simpler to implement and maintain.  In any case, I hope 
development of this feature doesn't block on decentralization.  While decentralization 
would be nice, it's not required; people can set up their own servers when they really 
need to.

Best regards,
-Karl

Hi Karl:

In the library level we could (and maybe should) implement both (OT and
CRDT). This will only require a hint from the server side (or the
connection starter client) to inform the client's libraries "what to use
this time". Then practice will say what's better.

ATM we could start with a C library in order to provide a nice free
back-end editor agnostic. Because IMO the most interesting part of this
will be to open emacs to interact with other editors with a free
infrastructure emacs-centric.

IMO: it should/must be like Tandem but made in C and using free
libraries. Without python or JS dependencies and with a JSON (or
standard interface).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]