In genannten Arbeiten wurde ein eigenständiger Server entwickelt, welcher das Hosten einzelner Saros-Sitzungen unabhängig von den Teilnehmern ermöglicht. Im Gegensatz zur vorhandenen Netzwerk-Architektur bei der ein Teilnehmer die Rolle des Hosts übernimmt, steht und fällt die Sitzung beim Client-Server-Betrieb nicht mit besagtem Host-Teilnehmer. Es besteht also die Möglichkeit zeitversetzt an einem Projekt zu arbeiten und trotzdem eine aktuelle Codebasis über den Server bereitzustellen und aufrecht zu erhalten. Auch ermöglicht der Serverbetrieb das ständige An- und Abmelden sämlicher Teilnehmer zu jeder Zeit.
Eine funktionierende Implementierung existiert, sie besitzt jedoch eine Liste von Schwachstellen, die zum täglichen Betrieb noch ausgemerzt werden müssen. Diese stellen gleichzeitig die minimalen Meilensteine für diese Arbeit dar. Weitere Verbesserungen sind denkbar und werden gegebenenfalls später hinzugefügt.
1. GUI-Integration
Die bestehenden IDE-Plugins von Saros behandeln den Server wie einen normalen Teilnehmer, was mindestens zu Verwirrung und teilweise zu Problemen beiträgt.
Der Server sollte als solcher im GUI erkennbar gemacht werden, Funktionen die im Kontext des Servers keinen Sinn ergeben, wie zB der Follow-Mode sollten nicht zur Verfügung stehen. Aktuell kann nur der Server Teilnehmer einladen (über Kommandozeilenparameter). Ein Betritt zu einer Server-Sitzung sollte sich aus der GUI realisieren lassen. Weitere server-spezifische Funktionen sollten abgebildet werden sobald realisiert, wie das Beenden einer Serversitzung.
2. Projekt-Sharing
Es besteht aktuell keine Möglichkeit ein bestehendes Projekt mit dem Server zu teilen. Zwei Ansätze sind hier denkbar. Ein Prototyp für den alten Mechanismus besteht noch aus der Arbeit von Herrn Washington, welche an die aktuelle Codebase angepasst und weiterentwickelt werden könnte. Desweiteren existieren Implementierungen des geplanten Features des Instant-Session-Starts. Diese neue Übertragungsmethode umgeht mehrere Problem des Non-Host-Projekt-Sharings und wäre daher bevorzugt. Die Methoden müssen getestet und je nachdem implementiert werden.
3. Jupiter-Speicherleck
Es existiert schon länger ein bislang unbehandeltes Speicherleck in der Implementierung des Jupiter-Algorithmus von Saros. Dieses wurde bereits in der Arbeit von Herrn Washington entdeckt und bislang nicht behandelt, weil es nur im Zusammenhang mit inaktiven Teilnehmer zu bemerken ist. Auch wenn es theoretisch jeden Teilnehmer betreffen kann, erreicht es daher zumeist nur im Serverbetrieb ein kritisches Ausmaß und muss daher gelöst werden.