Saros @ ICSE

Posted on May 14, 2010


ICSE 2010 is over. Those lucky enough to have gone have had their reward of first dibs on the material presented, so now I can present a brief summary of the paper that we in the Software Engineering group at Freie Universität produced for that conference.

The paper is both a way of announcing Saros to the academic world and providing a description of the software. Then again, the purpose of the description is twofold itself: the technical architecture of Saros is described, but more importantly, four concrete usage scenarios are elaborated upon that show the novel concepts behind Saros.

An introduction to Saros is covered in an earlier post.

Technical Overvew

The diagram below is an architectural overview of Saros (the green pieces wedged between the Eclipse application and the Smack libraries).

The Eclipse Bridge is responsible for capturing all of your local editing activities in Eclipse and also applying remote ones incoming from your peers. The job of managing the consistency of your project, ensuring that all concurrent edits are merged correctly on all participants, is done at the Concurrency Control level. Concurrency control is our improved version of the Jupiter algorithm. To deal with inconsistencies caused by such issues as external changes or network failures, the Consistency Watchdog constantly monitors all project resources using checksums. The Network Layer keeps everyone connected and built upon the XMPP Smack library. Finally, there is a Feedback Module, which (with the user’s permission) feeds anonymous usage data back to our central servers for research purposes.

Usage Scenarios

Our group proposes that at least four usage scenarios are facilitated by Saros, which would otherwise be a more complicated endeavour in a distributed environment.

  • Distributed code walkthrough: To familiarise a new developer with your project, it is often necessary to show and explain certain parts of the code. An experienced developer will act as the teacher, navigating through the code and explaining important sections. The student will try to follow the teacher, asking questions to gain a better understanding of what the teacher is talking about. If they are not co-located, this is a difficult thing to achieve. Using Saros you can the students can track the teacher’s viewport (using Saros’s follow-mode), as well as sharing “gestures” via text selections.
  • Distributed code review: A common and effective method in software projects, especially FLOSS projects, is code review. In this scenario, all developers are expected to contribute and find problems. Again, without being co-located, performing a code review is limited. Like the previous scenario, Saros provides a common reference point for a number of developers to inspect the code concurrently and exchange their knowledge or opinions.
  • Distributed pair programming: Distributed pair programming comes into play when developers want to do pair programming but are not co-located. Saros provides a means to enable this, by providing the concept of user-roles (driver and observer) and facilitating the carrying out of their responsibilities by allowing real-time editing, common code view and controlling the availability of mouse and keyboard (so-called floor control). To this end, the host invites the other developer and assumes the role of the driver, possessing control of the mouse and keyboard. The other developer is initially assigned to be the observer, but role changes can then be performed by the host to support the frequent changes in role assignment.
  • Distributed party programming: In contrast to previous scenarios, this style of collaboration is much more loosely coupled. Developers often ask for each other’s help, but usually for limited periods of time. In this scenario it is easy to see the downside of this scenario when co-located  because only a limited number of co-developers can sit in close proximity. When distributed, all members form a virtual team by adding each other to their project roster (similar to an IM buddy list). Saros sessions are started opportunistically when one team member asks another team members for help. Once a solution is found, team members can ‘leave the room’ and switch back to working independently.

Wait, There’s More

Finally, the paper also discusses the present opportunities and problems facing the Saros project, along with some of the feedback the project has received. It rounds everything off by describing the upcoming features that will (or already have!) been integrated into Saros.

Reference: Stephan Salinger, Christopher Oezbek, Karl Beecher, Julia Schenk. Saros: An Eclipse plug-in for distributed party programming. CHASE 2010 Workshop, co-located with 2010 IEEE International Conference on Software Engineering, Cape Town, South Africa, 2010.