code multiplexer -- fast, safe, collaborative editor plugin ecosystem
Find a file
alemi 5277eceb01 feat: reworked buffer controller
basically now calling recv assumes we have locked the editor state, and
no more operations will be enqueued. this allows to safely transform and
send server operations. the way local ops are transformed and sent is
still kinda buggy but it mostly works? "dead"locks sometimes until more
stuff arrives. also buffercontroller no longer implements operation
factory, you gotta make a factory yourself
2023-09-10 03:01:37 +02:00
.github/workflows ci: run CI with all features 2023-08-21 15:08:48 +02:00
proto fix: added proto docs, changed a little bit 2023-08-20 07:32:08 +02:00
src feat: reworked buffer controller 2023-09-10 03:01:37 +02:00
.editorconfig fix: editorconfig for yaml 2023-08-17 22:51:04 +02:00
.gitignore build: improved buildscript and bundle, added cmds 2023-07-04 01:02:50 +02:00
.rustfmt.toml build: initial commit with tonic stubs 2022-07-10 19:01:56 +02:00
build.rs chore: split cursor and buffer protos 2023-08-16 17:08:53 +02:00
Cargo.toml fix: attempt to solve client edits race condition 2023-09-05 20:13:09 +02:00
docs.html docs: simple html redirect 2023-08-19 21:45:58 +02:00
LICENSE fix: not really FOSS 2023-07-16 19:42:42 +02:00
README.md docs: mention about building docs 2023-08-20 01:22:54 +02:00

codemp

This project is heavily inspired by Microsoft Live Share plugin for Visual Studio (Code). While the functionality is incredibly good, I often find issues or glitches which slow me down, and being locked to only use Visual Studio products is limiting. I decided to write my own solution, and to make it open source, so that any editor can integrate it with a plugin.

Documentation

build the crate documentation with cargo doc and access the codemp page with the html redirect docs.html

Design

Client/Server

While initially a P2P system seemed interesting, I don't think it would easily scale with many users (due to having to integrate many changes on each client). I decided to build a client/server architecture, with a central "Workspace" managed by the server application and multiple clients connecting to it. Each client will only have to care about keeping itself in sync with the server (remembering local-only changes and acknowledged changes), leaving the task of keeping track of differences to the server.

Plugins

This software will probably be distribuited as a standalone binary that editors can use to connect to a "Workspace". A dynamic library object might also be a choice. Each editor plugin must be responsible of mapping codemp functionality to actual editor capabilities, bridging codemp client to the editor itself. The client should be able to handle a session autonomously.

Text Synchronization

A non destructive way to sync changes across clients is necessary. I initially explored CRDTs, but implementation seemed complex with little extra benefits from "more traditional" approaches (Operational Transforms). This has to be investigated more.