Google Summer of Code 2015 - Ideas

Content

1. How to read this page
2. Idea list
   1. Git support
   2. Features for Saros for IntelliJ IDEA
   3. Saros server
   4. Instant session start
   5. Whiteboard in HTML5
   6. Archnemesis issues plugin

General information

Check out this quick overview if you want to know more about Saros itself.

The required technical skills for participating in the Saros project depend on the respective area you want to work in. As a programming language, we use Java; we develop Saros as a plugin for both Eclipse and IntelliJ IDEA, so any experience in these areas might come in handy. Due to the nature of Saros (collaborative text editor), it has some quite distinct features: it's a concurrent, distributed, real-time software.

How to read this page

Each idea description contains the following parts:

• First, there is some Background information on basic Saros concepts, including their up- and downsides.
• Then, the current situation: What we already did to lessen the problems while keeping the benefits.
• The Project: What should be done to better the situation even more.
• In some cases, we already gathered Some Thoughts on what ways we could go.

Contact: Franz Zieris (zieris@inf.fu-berlin.de)

Idea list

Git support

Background: In principle, Saros works orthogonal to traditional version control systems: It keeps the respective files in sync, regardless of whether they are part SVN or Git working copies -- or just plain folders and files. This also means that, by default, any VCS action (such as svn/git commit, svn checkout, git pull) needs to be performed by both Saros session participants to achieve consistency of the meta-data.

The current situation: To make that workflow less cumbersome, we developed support for SVN (only for the Eclipse version of Saros, though, and only for Subclipse): So an svn commit on one side leads to an svn update on the other side. Furthermore, starting a session is faster since instead of transferring all of the project files, the invitee only needs to know the url and revision for an svn checkout.

The Project: Implement Git support for Saros.

Some Thoughts:

• The easy case: Both developers have access to a shared Git repo. For this centralized scenario, the Git implemenation is merely a re-implementation of the SVN support.
• The Git-way (1): One of the developer's repository can already be accessed by the other developer through one of the standard Git ways. Then, a session start can be achieved by a git pull; git commits should be followed by a git reset + git pull (or git reset on one side/git push on the other, respectively).
• The Git-way (2): If none of the standard protocols between the two developers is possible, Saros could provide a bridge, e.g. if Alice and Bob are in a Saros session, Bob pulls from a "remote" repository at localhost:<some port> which is a proxy for Alice's Git repo -- the actual communication is done via Saros.

Special requirements:

• Profound knowledge of Git concepts; experienced Git user.

Features for Saros for IntelliJ IDEA

Background: Traditionally, Saros is an Eclipse plugin. Early 2014, we started to extract an IDE-independent core which could then be used by a new IntelliJ IDEA plugin.

The current situation: The IntelliJ IDEA plugin (i.e. Saros/I) basically works, but it could use a deeper integration into the IDE. We collected some feature requests on SourceForge.

The Project: Help us to improve the IntelliJ integration of Saros/I, in particular regarding the optics (#113, #114, #115, #116, #117) but also the functionality (#118).

Saros server

Background: Traditionally, Saros session require one Host to synchronize all participants' activities. That role is fulfilled by the initiator of the session. This leads to a star topology which easily allows to scale Saros sessions up to more than two users. But there is a downside: If the Host leaves the session, it will be closed for the other participants as well. Since all files are local, they can continue their work, but they have to start a new session to get in sync again. A user-independent, long-running session would help with that: There still would be Host, but it's non-human and always online -- a server.

The current situation: We started working on a simple server implementation which is a normal Saros instance running in Eclipse but without the need for human interaction. Instead of having to initiate a session from the Host instance by sending an invitation to other users, the human users can send an invitation request to the server, and so on.

The Project: Implement a Saros server that can run headless in a non-graphical environment, i.e. without the need of a full-blown graphical IDE.

Some Thoughts:

• In the process of supporting IntelliJ IDEA, we've been extracting the Saros core, containing the "business logic". This would be the basis to build a headless server.

Instant session start

Background: Saros offers two ways to start a session, by starting from scratch, i.e. transferring all the project's files, or by reusing an existing project on the invitee's side, transferring only the diff (based on the files' checksums). Either way, the necessary files are compressed in a ZIP archive and only after that archive is received and extract, the actual session can start. During the session, however, any newly added files are transferred using the "standard Saros way" of sending activities.

The current situation: We are playing around with the idea to skip the zipping part and start sending activities right away, i.e. the invited developer would join an empty session and all the files would be added through FileActivities.

The Project: Implement the instant session start so users can join sessions without needing to wait for some process that could also run in background.

Some Thoughts:

• Transferring all files through activities still can take a while. For the user, it's necessary to get important files first. This would be IDE-specific meta-data (e.g. the .project file in the case of Eclipse), and right after come the files the developer want to work on. One idea: As soon as one developer already in the session opens one file, the according FileAddActivity skips the queue of all activities, so the invitited user receives that content first. Another idea would involves "files proxies" (e.g. 0-byte-files) which upon opening have the same effect: Telling the inviter to prioritize the FileActivities for that file.

Whiteboard in HTML5

Background: The Saros Whiteboard is another Eclipse plugin that comes along with Saros. Just as Saros allows concurrent editing of source code in realtime, the Saros Whiteboard does the same with graphical elements.

The current situation: The current released version has some major drawbacks, so we set out to redesign it, which was actually done, but the patch was far too big to review. In the meantime, we split the big patch into smaller ones and are gradually adding them to the code base. However, even the new Whiteboard still relies on the Eclipse Graphical Editing Framework (GEF).

Comparison of the current (old) Whiteboard (left) and the new, theoretically almost-done Whiteboard (right).

Furthermore, we are currently re-implementing the GUI of Saros using web technologies (HTML, JavaScript) so it becomes IDE-independent (the old Eclipse-GUI used SWT).

The Project: Re-implement the GUI of the Saros Whiteboard using modern web technologies. This would kill two birds with one stone: First, the new usability-improved Whiteboard look can finally reach the end-users. Second, using IDE-independent technologies (such as HTML and JavaScript) make it easier to provide the Whiteboard not only for Eclipse, but also for IntelliJ IDEA in the future.

Archnemesis issues plugin

Background: We developed a architecture description language called "Archnemesis" which we use to describe architectural constraints in software project. The according file for the Saros Eclipse plugin lies here. We also equipped our SonarQube with a custom plugin which performs the architecture compliance check of the source code against the formulated rules. Finally, a this tool extracts the reported issues, and includes them as inline comments into the patches during our normal review process. This way, we can prevent that newcomers in the project violate important architectural rules without anyone noticing.

The current situation: The architecture compliance check is executed by our CI infrastructure every time a developer pushes a patch for review. It could be nice to have the same checks available on your local machine, e.g. in the form of an Eclipse plugin that annotates any violations directly in the code

The Project: Implement an IDE plugin (for Eclipse and/or for IntelliJ IDEA) that performs an architecture compliance check based on the defined Archnemesis rule set.

Some thoughts:

• This would not be the first custom-but-yet-generic Saros development tool. Some years ago, we developed JTourBus which an easy way to navigate through source code.
• The compliance check itself is already performed by the Archnemesis-SonarQube-Rule. Therefore, it should be relatively easy to extract a resuable part of the SonarQube plugin to create an IDE plugin.