Updates

• 23. November 2024

Ich wurde über einen Post auf Mastodon auf ein Projekt aufmerksam, das mir so interessant erschien, dass ich daraus meine neueste Fingerübung machte...

Dieses Projekt definiert und implementiert ein Protokoll, das es erlaubt, an einem Rechner kollaborativ zu mehreren Personen an einem Textdokument zu arbeiten. Änderungen, die einer der Mitarbeitenden durchführt, werden damit sofort an alle anderen Editoren übertragen und dort transparent eingearbeitet, sodass alle Nutzer immer über einen aktuellen Gesamtüberblick über alle zusammengefassten Änderungen verfügen. Das Projekt stellt den Quelltext für den Server und die bereits existierenden Plugins für nvim und (geplant) VS Code auf Github als OpenSource unter AGPLv3+ zur Verfügung.

Meine Idee - nachdem ich mir die Dokumentation des Protokolls angesehen hatte - war, dass ich die in Java (Swing) vorhandene Komponente JTextArea zum Editieren von Text eigentlich recht einfach um Unterstützung dieses Protokolls erweitern könnte.

Wie sich herausstellte, war das doch nicht so einfach - ich öffnete daher ein Issue im Projekt und durch die sich daraus entspinnende überaus schnelle, ausführliche und kompetente Diskussion konnte ich die diversen Stolpersteine umschiffen - ich baute das schnell hingerotzte Skript danach noch ein wenig um und nach einem drastischen Refactoring war ich in der Lage, das Projekt unter dem Namen ethersyncj ebenfalls als OpenSource unter AGPLv3+ zur Verfügung zu stellen.

Die Stolpersteine waren im einzelnen im (fehlenden) Verständnis des Protokolls begründet: Unter anderem hatte ich übersehen, dass das verwendete Protokoll \r\n als Zeilenende erwartete und das Ende jeder Botschaft als Zeilenende erwartet wurde. Aber auch Java selbst wartete mit einigen Überraschumgen für mich auf: Die Tatsache, dass Java erst seit Version 16 Unix Domain Sockets nativ unterstützt gehörte genauso dazu wie der Fakt, dass `java.io.File.ToURI` keine korrekten file-URIs erzeugt: das Ergebnis dieses Aufrauf sieht zum Beispiel so ais: file:/tmp/some.file - möchte man eine korrekte URI erzeugen, muss man statt dessen `java.nio.file.Path.ToUri` benutzen, die für den gleichen Input mehr Slashes erzeugt: file:///tmp/some.file - Das führte natürlich zu einem sofortigen Update meiner Regeln für ArchUnit und damit auch zu einem größeren Refactoring meiner gesamten Codebase...

Außerdem - und das war dann doch wieder eine Diskrepanz im Protokoll - erzeugte ich die IDs, die in jeder Botschaft mitgesendet werden müssen als zufällige UUIDs, die ich in über eine BigInteger-Instamz in eine Zahl wandelte. Diese Zahl hatte eine Breite von 128 Bit, womit die Rust-Implementierung des Servers nicht umgehen konnte.

Ich werde noch einige weitere Arbeiten daran vornehmen - eine weitere Idee ist, den SQL-Editor in der sQLshell - unter Umständen als Plugin - ebenfalls in die Lage versetzen, dieses Protokoll zu unterstützen.

Aktuell findet man in der Dokumentation einige UML-Diagramme, die bei der Benutzung der Lösung und beim Verständnis der Implementierung helfen sollten - der Bequemlichkeit halber habe ich sie hier nochmals wiedergegeben:

Kommunikation

Erzeugung/Benutzung

Klassendiagramm

Aktualisierung vom 23. November 2024