Entwicklung eines Saros-Servers

worked on by: Nils Bussas

Outline

Saros wird bisher mit einer Peer-to-Peer-Architektur betrieben, bei der einer der Teilnehmer der Host einer Sitzung ist und dadurch Sonderrechte genießt. Es wird von manchen Benutzern gewünscht, parallel dazu eine Client-Server-Architektur bereitzustellen. Vorteile eines solchen Systems sind, dass man in einem Team nicht zwangsläufig zur selben Zeit arbeiten muss, um sich über Saros gegenseitig auf dem neusten Stand zu halten. Wenn ein Server existiert, verfügt dieser zu jedem Zeitpunkt über den aktuellen Stand des Programmcodes. Ein solcher Server soll mehrere Sitzungen (in meiner Version zunächst nur eine) verwalten, in die sich die Mitglieder eines Teams bei Bedarf einklinken können. Für den Client muss zu erkennen sein, welche Sitzungen beim Server laufen. Anders als bisher muss es für ihn auch möglich sein, als Client ein Projekt zu einer Sitzung hinzuzufügen und weitere Benutzer einzuladen. Darüber hinaus muss es für ihn möglich sein, den Server aufzufordern, eine Sitzung zu beenden.

Bei der Umsetzung dieses Plans stellen sich mehrere Fragen:

1. Wird der Server als eigenständiges Programm implementiert oder wird er, wie der Host bisher auf, von Eclipse aus betrieben?
   Es ist in Planung, Saros von Eclipse abzulösen, d.h. die Kernfunktionalität wird von den Schnittstellen zu Eclipse getrennt. Das Ziel davon ist, Saros für weitere IDEs verfügbar zu machen.
   Dies wird als recht große Aufgabe angesehen. Für meine Bachelorarbeit ist dieser Ansatz also aus zwei Gründen ungeeignet. Erstens ist er zu aufwändig und zweitens würde ich hier Arbeit verrichten, die in einem anderen Kontext nochmals gemacht werden müsste. Von daher wird der von mir implementierte Server eines speziell konfiguriertes Saros-Plugin in Eclipse sein.
2. Stellt der von mir implementierte Server bloß ein “Proof of Concept” dar und wird von späteren Entwicklern für die finale Version nochmals implementiert oder erstelle ich schon eine “Alpha-Version” des eigentlichen Saros-Servers?
   Aus dem vorigen Punkt ergibt sich schon, dass das von mir entworfene Design nicht von Dauer sein wird. Jedoch bezieht sich das nur auf die Oberfläche, die Programmlogik kann weiterhin verwendet werden. Ich habe mich entschlossen, die von mir entwickelte Funktionalität laufend in Saros zu integrieren, um einerseits zu verhindern, dass sich mein Code und die reguläre Entwicklung von Saros zu stark von einander entfernen, was beim Zusammenführen zu größeren Konflikten führen würde, und andererseits, um laufend Feedback zur Codequalität zu bekommen.
   Daher ist davon auszugehen, dass der von mir entwickelte Code von nachfolgenden Entwicklern übernommen werden kann und nicht als bloßer Prototyp dienen wird.

Thesis Requirements

• Clients müssen anfragen können, welche beim Sitzungen beim Server laufen.
• Sitzungen müssen clientseitig gestartet werden können. (präziser: Der Client fordert den Server dazu auf, sie zu starten.)
• Clients müssen Projekte in einer laufenden Sitzung hinzufügen können.
• Clients müssen in der Lage sein, weitere Nutzer zu einer Sitzung hinzuzufügen
• Zu den oberen Punkten müssen passende Benutzerschnittstellen entworfen werden.

Milestones and Planning

A milestone is a scheduled event signifying the completion of a major deliverable or a set of related deliverables. A milestone has zero duration and no effort -- there is no work associated with a milestone. It is a flag in the workplan to signify some other work has completed. Usually a milestone is used as a project checkpoint to validate how the project is progressing and revalidate work. (Source: http://www.mariosalexandrou.com/definition/milestone.asp)

Milestone no.	Past	KW	Goals
0		KW48	Arbeit anmelden
1		KW49	Einleitung schreiben
2		KW49	Laufende Sitzungen abfragen
3		KW50	leere Sitzung fernstarten
4		KW52	Client: Projekte hinzufügen
5		KW02	Client: Peers hinzufügen
6		KW04	Benutzeroberflächen
7		KW06	Puffer
8		KW07	(Fertig-)schreiben
9		KW08	Letzte Feinarbeiten
10		KW08	Abgabe