Re: Question collaborative editing.

[Ergus <spacibba@aol.com>]

On Fri, Oct 02, 2020 at 09:30:53AM +0200, Michael Albinus wrote:
>Ergus <spacibba@aol.com> writes:
>
>>>> It is a bit more complex, because for remote editing it is not easy to
>>>> establish connection in different NAP, cross firewalls, and so on. And
>>>> as I said before, we don't have resources to provide a server service
>>>> for this that runs "our" CRTD server.
>>>>
>>>> Withing the same network it still requires a sort of local service to
>>>> solve the conflicts. And that also needs to be implemented...
>>>
>>>Well, we can start with something simple. How about implementing
>>>collaboration on local area network first. I remember we had fun with
>>>'talk'. Once implemented on LAN, users can then figure out how to work
>>>across continents using some kind of tunnel.
>>>
>>>An example use-case might be:
>>>
>>>user1:
>>>1. C-x C-f (find-file)
>>>2. M-x enable-collaboration ; this generates a session-key
>>>3. Share session key with collaborators via chat/email
>>>
>>>user2: (via Tramp)
>>>1. C-x C-f /collab:session-key@ip-address:filename <RET>
>>>
>>>Users get cursors with different colours.
>>>
>>>The advantage of using Tramp is that users can always use Ad-hoc
>>>multi-hops.
>>>
>> Yes, this is exactly my expected workflow more or less. It is p2p as I
>> have mentioned before I would prefer it to be. The tramp integration is
>> something way far from my capabilities, but in general that's the
>> idea ;).
>
>I don't want to be the grinch, but pls remember what Tramp is: a library
>for alternative implementations of file operations. I don't see yet how
>/collab:session-key@ip-address:filename fits into the game, but maybe it
>needs more details to understand. For example, which file operations
>shall be treated.
>
Hi Michael:

I don't have any clear idea yet (and don;t know the TRAMP code). But, as
this will be implemented more or less as a server-client, the only thing
tramp would need to do is to connect (from the client side), identify
and request the file... very similar to opening an ssh file, but maling
a local copy and initializing the server CRDT/OT local service as
client. The rest of the process will be handled internally by the
collaborative api like any other file from the Tramp's point of view.

I think tramp is the preferred place to avoid creating another interface
for the user (extra names, commands and so on). But actually the only
part that Tramp should take care may be the initial "login" and probably
the logout/close-connection.

In any case this could also be implemented from outside tramp and add a
condition to commands like find-file... But IMO these are just
details.. we need to make it work first.

>Furthermore, I also don't understand what needs to be done on the remote
>side wrt collaboration. A remote file in Emacs is still a file,
>connected to a buffer. All primitive file operations can be applied on
>this.
>
In local or remote side the requirements are similar (From the tramp
point of view):

Server side:
Start the OT/CRDT server/service
Associate with a local file(s)

Client side:
Start the OT/CRDT server/service (as client)
Connect to remote server
Identify
Request/create remote file copy to work locally.
Associate

>Best regards, Michael.
>

Best,
Ergus