Schnellerer Sitzungsstart in Saros
In der heutigen Zeit spielt die Koordinierung von verteilten Entwicklern
eine immer größere Rolle in der Softwareentwicklung.
Saros ist ein Eclipse-Plugin, welches unter anderem dieses Szenario unterstützen soll.
Die Entwickler können mithilfe von Saros auch über weite Entfernungen gemeinsam an einem Projekt arbeiten.
Im Moment ist Saros nur für Eclipse verfügbar, es wird aber an einer Portierung auf IntelliJ gearbeitet.
1 Aktueller Stand
Wenn Entwickler zusammen an Quellcode arbeiten wollen, dann müssen sie
dafür erst die benötigten Ressourcen austauschen. Bei größeren Projekten
kann es dabei zu längeren Wartezeiten kommen, da diese Ressourcen erst archiviert,
dann verschickt und dann auch wieder entpackt werden müssen.
Während dieser Zeit müssen die Entwickler warten, bis sie anfangen können zu arbeiten.
Um den Sitzungsaufbau zu beschleunigen, gibt es bereits eine Unterstützung
für SVN-Projekte. Dabei benötigt der Saros-Client des Empfängers nur die URL und die Versionsnr. der Ressourcen und
kann dann das Projekt über das Subclipse-Plugin herunterladen.
Während einer laufenden Sitzung werden die Veränderungen an den geteilten Projekten
mittels Activities übertragen.
2 Ziele
Das Ziel dieser Arbeit ist es, den Sitzungsstart im Saros Projekt für den Nutzer möglichst
kurz zu gestalten. Dabei soll die Zeit, die zwischen dem Absenden der Einladung und dem Zeitpunkt,
an dem der Nutzer anfangen kann zu arbeiten, verkürzt werden.
3 Ansätze
Eine Möglichkeit wäre es, den Sitzungsaufbau auf den Austausch von Metadaten zu
beschränken und die benötigten Ressourcen im Hintergrund mittels Activities zu verschicken (siehe
Abschnitt 3.2).
Außerdem könnte man hier auch in Erwägung ziehen die Activities je nach Bedarf
zu priorisieren, sodass eine ausgewählte Ressource in der Activity-Warteschlange
bevorzugt wird (siehe
Abschnitt 3.2).
Eine weitere Verbesserungsmöglichkeit wäre es, neben dem direkten Laden der
Ressourcen aus dem SVN noch ein weiteres Feature für Git-Systeme anzubieten.
3.1 Resourcen per Activities übertragen
Der erste Teil der Arbeit besteht darin, einige Vorbereitungen an dem bestehenden Code zu treffen, um
dann später die Activities für die Übertragung größerer Projekte zu nutzen.
Zum einen müsste darauf geachtet werden, dass der Java Heap nicht zu voll wird.
Ausgehende Activities werden solange auf dem Heap gespeichert, bis sie verschickt werden.
Wenn mehr Activities erzeugt als verschickt werden, kann es passieren, dass irgendwann kein freier Speicher mehr auf dem Heap zur Verfügung steht.
Ein weiterer Punkt ist das Blockieren der Benutzeroberfläche während neue Dateien angelegt
werden. Hier könnte man das Erstellen im Hintergrund ausführen und die Events, die
ausgelöst werden, sammeln und gemeinsam freigeben. Dadurch würde der Nutzer bei größeren Projekten nicht
unterbrochen werden.
Die Übertragung mittels Activities würde außerdem dazu führen, dass
der Wartungsaufwand der Software leicht reduziert werden könnte, da die Archivierung
nun nicht mehr benötigt wird und ausgebaut werden kann.
3.2 Priorisierung der Activities
Im zweiten Teil der Arbeit wird dann die Priorisierung der Activities näher
betrachtet. Mögliche Nutzungsszenarien würden folgendermaßen aussehen:
- der Host wählt eine Ressource aus seinem Paket-Explorer aus
- der Eingeladene besitzt eine Liste von Platzhaltern, unter denen er die zu bevorzugende Ressource auswählen kann
Eine wichtige Rolle spielen hierbei die Abhängigkeiten der Activities, da einzelne Activities zeitlich
abhängig von anderen Activities sein können. Zum Beispiel kann eine Resource erst bearbeitet werden, nachdem sie erstellt wurde.
4 Evaluierung der Ergebnisse
Zur Überprüfung der Ergebnisse dieser Arbeit wird regelmäßig die Zeit, die für den Sitzungsaufbau
benötigt wird, gemessen. Hierbei werden unterschiedlich Nutzungsszenarien betrachtet.