Designing and Implementing Cross-IDE Compatibility for Saros

worked on by: Tobias Bouschen
due by: 2020-06-30 (CW 27) Moved back due to Corona Pandemic (FU announcements)
due by: 2020-11-09 (CW 46)
initial presentation slides: PDF

Outline

Saros is a plugin designed for distributed pair/party programming*. Its goal is to provide the technical infrastructure for developers to concurrently collaborate on shared resources without being co-located. Furthermore, it provides the benefit of allowing the users to work in their usual work environments (IDEs) using their own configuration, thereby increasing the productivity of pair programming sessions.

Saros was initially only designed for Eclipse, but later on was adjusted to also be available for other IDEs as well (mainly IntelliJ, but support for other IDEs would also be possible and was/is being worked on by other theses). The introduction of additional implementations for other IDEs broadened the usability/potential user base of Saros but also led to a new difficulty: Saros implementations for different IDEs were not cross-compatible.

Providing such cross-IDE compatibility would further increase the benefit of allowing the users to work in their usual environment by bridging the gap between different IDE users, thereby furthermore broadening the potential user base and use cases for Saros.

Pair Programming Footnote

If you are not familiar with pair programming, you can read this recent article from Martin Fowler about it.

Goal of the Thesis

The goal of this thesis is to analyze the current structure of Saros, identify roadblocks on the way to supporting cross-IDE compatibility, and create a design for a cross-IDE-compatible Saros. Furthermore, once such a design has been finalized, a list of steps to take to reach this design is created and the implementation of these necessary steps is started. The implementation process of the necessary steps will most likely not be finished as part of this thesis, but it should still provide substantial effort in this process.

Related Work

As already mentioned, there was already put substantial effort into extracting the Saros Core through multiple theses:

Furthermore, this work was also continued through non-thesis-work by multiple Saros contributors over the years.

The process of creating a better IDE abstraction was also started more recently with the master's thesis "Saros: Refactoring the Filesystem" by Oliver Hanßen (2019) (written in German), which worked on providing a basic design for making the filesystem implementation IDE independent by moving to a reference point system.

As an almost all-encompassing work on Saros, a general overview of the field of agile development and pair/party programming as well as Saros, its development history, how it compares to other, related tools, and a detailed analysis of the design of Saros measured under the viewpoint of usability in an industrial setting is given in the dissertation "Industrially Usable Distributed Pair Programming" by Julia Schenk (2018).

Issues With Cross-IDE Compatibility

Saros was initially designed solely as an Eclipse plugin. As other IDE implementations were never planed, the interface and software architecture design was heavily based on Eclipse models to make the integration as easy as possible.

Later on, the idea of providing Saros implementations for other IDEs (namely IntelliJ) gained traction, leading to substantial efforts being made to extract any IDE-independent Saros business logic into a separate component, the Saros Core. The basic design and architecture of the logic was however not adjusted, leading to a situation where the Saros core components still contain many assumptions of how different IDE concepts work that are heavily based on the Eclipse model.

As a result, implementing Saros for other IDEs is not as easy as it could be due to some aspects of the core interfaces being to specific (and closely modeled after Eclipse counterparts), leading to issues when trying to implement them for other IDEs.

An important factor for this thesis is that I make sure that my knowledge of the Saros/I implementation and the used IntelliJ API does not influence the design process in a similar manner. Otherwise, the resulting architecture/logic could suffer from the same issues.

Thesis Requirements

formulate requirements here (together with your adviser)

Milestones and Planning

# Past Date CW Goals
1 28.01.20 CW05 A basic overview over the Saros architecture and possible roadblocks has been achieved
2 21.02.20 CW08 The list of steps to take on the way to implementing IDE cross-compatibility has been compiled
3 27.06.20 CW26 The Saros filesystem interface has been revamped
4 27.06.20 CW26 Basic IDE cross-compatibility is implemented

The list of steps to take on the way to supporting IDE cross-compatibility is quite extensive. The milestone of having refactored the filesystem handling is quite arbitrary and was chosen before the list of steps was defined. However, as the refactoring is probably the largest single task, it still offers a good milestone to compare progress against. The list of milestones might still be adjusted during the process of working on the defined steps.

Milestone 1 – Initial Roadblocks

To identify roadblocks, I had a general look through the existing packages and classes in the Saros Core, Saros/E and Saros/I. Furthermore, I encountered some of these issues while working on Saros/I.

Initially, I have identified the following roadblocks:
  1. The Handling of Modules/Project
  2. The Handling of Editor Contents
  3. The Handling of Binary Files

For an extended list of additional roadblocks discovered along the way, see Additional Roadblocks.

Roadblock 1 – Issues With the Current Project/Module Handling

This is by far the largest roadblock (requiring the largest amount of work) I have identified so far.

As already hinted at in the previous section, the workspace handling in general poses an issue. Even when mapping concepts of other IDEs onto the current Saros project interfaces, the underlying implementation will still be IDE specific. This can lead to a confusing mix of names/concepts in the implementation, especially when naming schemes clash in the different IDE concepts (e.g.the usage of the term "project").

As a more pressing issue, when trying to create a session between different IDE implementations, these (superficially hidden) implementation details can become an issue.

This is due to the concepts of Eclipse projects and IntelliJ modules being far to different to allow for a clean mapping. This especially becomes an issue when trying to create a module as part of the project negotiation or when working with more esoteric module setups (e.g. weird content roots, custom languages, etc.). Even with relatively normal setups (like the Saros project itself), a mapping between Eclipse projects and IntelliJ modules is far from trivial: Eclipse sees each root "project" (e.g. Core, Eclipse, IntelliJ) as one project. IntelliJ, on the other hand, imports every "project" (e.g. Core, Eclipse, IntelliJ) through Gradle as three modules, each containing different parts of the tree (a base module containing everything but no mapping for "source" roots, a "main" module containing the source roots and resources, and a "test" module containing the test roots and resources). Furthermore, some of these module contain multiple content roots, meaning such modules can't be represented as a unified tree (without including parents outside the module).

All in all, trying to manage IDE concepts works when only connecting to implementations for the same IDE as we can then add very IDE-concept specific handling logic (which is what has been done while implementing Saros/E and Saros/I so far). Trying to map these concepts between IDEs is far to complex to maintain, even for "normal"/"simple" project setups.

An alternative that was already suggested in the thesis of Oliver Hanßen (see section Related Work) is to use the concept of "reference points". This would change the Saros infrastructure to simply share resource trees based on a reference point in the filesystem instead of IDE-determined units of content (e.g. projects/modules).

This would mean that we would loose some more tightly integrated IDE features (such as creating and registering a project/module as part of the negotiation) but would (in the end) simplify the resource handling logic and make the adoption of new Saros implementations far easier.

My current plan is to have another stab at trying to implement such a large scale refactoring to move the Saros filesystem to a reference point based system.

During the implementation, special attention will also have to be given to the restrictions which reference point setups are allowed. Nested reference points make the implementation a lot more difficult as they don't have to be nested for all participants. So it would be easiest to require all reference points to be non-overlapping, meaning each reference point symbolizes a resource tree that is completely distinct from every other reference point resource tree.

One of the "normal" use cases that would be excluded by such restrictions would be to first share only a sub-tree but then later on during the session decide to share the entire project tree. A workaround would be to quietly terminate the session for all users in the background and re-open it using the new reference points. But this issue has to be discussed in more detail when the actual design for the reference point implementation is created.

Roadblock 2 – The Handling of Editor Contents

In IntelliJ, all editor contents are normalized to use Unicode characters and UNIX line endings.

As this is not the case for other IDEs (like Eclipse), I will need to implement a bridge that is able to convert between normalized and non-normalized content.

This should, however, only be an issue for line endings and not for character encodings. As we are already using Java Strings to exchange document content modifications, which all use the Unicode charset, this part of the normalization should already be taken care of by the IDE. Line endings, however, will have to be dealt with by us.

The only situation where the encoding still is an issue is when we are reacting to a remote file creation. At that point, we will have to decide which encoding to use for the newly created file. To ensure that we don't break the local project setup, I decided to also use the encoding used by the creator of a resource when creating it for all other participants. (The encodings might still differ for existing files when starting a session. My current stance on this is to see such files as having the same content as long as their editor contents match. In short, the encoding for existing files is ignored by the Saros session.)

Where this bridge is located, i.e. whether we want to always deal with normalized or non-normalized content in the general logic, has to be further discussed when I am actively working on this roadblock.

Dealing with editor content normalization also brings along other issues when dealing with offsets. When working with CRLF files on the one side and LF files on the other side, the offsets will not match, even when, for the user, the same text was selected. This is due to the CRLF line breaks (`\r\n`) being counted as two characters and LF line breaks (`\n`) as only one character. To avoid having to manually calculate the offset correction for every incoming and outgoing selection and text change activity, it would be preferable to replace the current position handling. Currently, positions in an editor are specified through an offset from the start of the file. Sections of text are specified through an offset and a length. To avoid offset issues, positions in a file can alternatively be specified as a line number and an in-line offset. Selections can then be specified as two sets of line numbers and in-line offsets. This removes the need of offset corrections as the transferred values are line-ending agnostic.

In a more edge case scenario (which we probably should not support), when working with incompatible encodings, incorrectly parsed character sets can also lead to single characters being expanded to multi-character series in the local editor, thereby requiring to non-trivial offset-conversions. But, since this case is not a viable working environment (since content is displayed incorrectly), we can probably safely ignore such cases.

As a solution, I am currently leaning towards normalizing everything for internal processing and locating the conversion bridge between the Saros logic and the IDE logic.

This does require more work (since it seems like IntelliJ is the outlier with its default normalization handling), but it allows us to use a unified handling and convert the content to the correct encoding for each client. This becomes more important with the move away from sharing projects/modules. Previously, sharing a project (this does not apply to IntelliJ modules, but that is besides the point) gave us control over the encoding and line ending settings for all resources as they were determined on a per-project base. With the introduction of reference points, we no have a way of influencing the encoding/line endings of the only the shared resources as we no longer necessarily share a complete project.

Making the session completely work with normalized information would also require an adjustment of the project negotiation. Currently, the content used for the negotiation is solely determined by the file content on disk, meaning the encodings and line endings of all clients are overwritten by the ones of the host. This is no longer an acceptable handling with the new normalization logic. Instead, the content of the editor should also be used (for non-binary files) during the negotiation.

Roadblock 3 – The Handling of Binary Files

IntelliJ IDEA does not open editors for files it does not have a file type mapping for. This is important as the normalization and subsequent writing back to the file could damage it when opening binary files in an IntelliJ text editor. As a consequence, the contents of binary files can not be accessed through the editor API.

To resolve this issue, a distinction between binary and non-binary files should be introduced to the core filesystem interface.

This different handling of binary files should also be extended to the watchdog, the logic checking for workspace consistency between the participants. Since binary files might not be openable in an editor, simply using the on disc content for checksum creation would be preferable. This still leaves the issue of dealing with editors for binary files (or rather the lack thereof), which would have to be dealt with separately to ensure that it does not break the follow mode.

Another general approach, would be to completely ignore content changes to binary files as Saros doesn't have any way of determining partial changes. Instead, we would always have to replace the entire file content on every change. As far as I can tell, this is already largely the approach taken in Saros/E (as "shared" images, for example, are ignored in the session; they are seen as "not having an editor selected" when in follow mode).

Additionally, the negotiation and watchdog should be adjusted to check for mismatches in which files the different participants see as binary. Such mismatches can not be handled by Saros. If such a mismatch is detected, it should notify the user to either exclude the resource from the session or adjust the IDE configuration of all participants to get a unified understanding of which resources are seen as binary. Afterwards, a restart of the session will probably be required to create a clean initial state.

Additional Roadblocks

During the planing and development process of the thesis, the set of initial roadblocks expanded due to new insights into the problem or newfound restrictions of the solution approaches.

  1. Determining Which Resources to Share

Roadblock 4 – Determining Which Resources to Share

(discovered 30.01.2020)

Generally, projects/modules contain resources that should not be shared through Saros, mainly automatically generated artifacts or files containing user specific data. The broadest definition of such resources would be "files that should not be kept under versioning", i.e. that should be ignored by the used version control system (e.g. git, svn, etc.).

The current approach of Saros is to use the local IDE mechanism to determine which resources to ignore. Eclipse offers the concept of derived resources and IntelliJ the concept of excluded resources for this purpose.

The issue with this approach is that, in both cases, these concepts are generally only used to mark resources that are generated as part of the compilation process. There are, however, other automatically generated resources and resources that contain user specific data (e.g. project/module configurations when using build tools like gradle) that should not be shared between Saros instances.

When implementing Saros for just one specific IDE, it is quite simple to cover most of these special cases with dedicated logic to exclude such resources as they can be queried from the IDE. This, however, only works if the set of non-shared resources determined through the IDE specification is the same for all participants. If participants use different IDEs, the set of such addition non-shared resources will very between the participants. To resolve this, a dedicated negotiation process would be necessary to first determine the maximal set of non-shared resources for all participants.

This additional negotiation step is quite cumbersome and furthermore complicates the already complicated negotiation logic. Furthermore, as already stated before, this covers most, but not all of such files and relies on the projects to be correctly configured in the IDE (which, for example, Saros isn't for Eclipse).

To avoid this case, it would be best not to solely rely on the locally configured, IDE-specific way of determining what is not supposed to be share and rather implement a general way of determining this. This would lead to the user being offered two option when starting a session: either share everything in the selected tree (already speaking from the view point of sharing reference points) or select some way to determine what is shared and what not.

This additional way of determining what shouldn't be shared in the current project/module can take many forms. The easiest solution is to offer a dedicated '.sarosignore' file specifying which resources to ignore (modeled after '.gitignore'). But, creating a general interface for this exclusion logic means we can also offer multiple implementations. A prime candidate for additional implementations are integrations with version control systems (i.e. by requesting the user to specify a '.gitignore' file to use) as they already require the needed information on what to keep under versioning (i.e. what to "share") anyways.

This approach still requires the host to transfer their list of non-shared resources to the clients as their local settings might differ from the ones chosen by the host. As a result, with the new logic, the settings chosen by the host will be used for all session participants. This should not be an issue in the envisioned general use case where a configuration file of a version control system is used as such files are generally also kept under versioning, meaning they are the same for all participants. Furthermore, if some participants have issues with the settings chosen by the host, they still have the option to adjust the settings prior to the session start.

Update:

If the host has to determine which resources are shared, offering to use the locally excluded/derived resources is an acceptable option as well. As mentioned above, they won't be usable/useful in all cases, but this is up to the user to decide. Furthermore, as the implementation already exists, implementing the backing logic to offer such an option is trivial.

Milestone 2 – Steps on the way to providing IDE cross-compatibility

NOTE: These steps are currently still a WIP and might change considerably during the initial phase of the thesis.

To allow for basic IDE cross-compatibility, the found roadblocks need to be resolved. To do so, the following steps need to be implemented. The order in which the steps are listed here is somewhat arbitrary and does not mean that the steps necessarily have to be implemented in the stated order.

  1. Preparation for the Filesystem Handling Refactoring
    1. Removal of the Partial Sharing Logic
    2. Extraction of Core Components That Need to Resolve Project Resources
  2. Refactoring the Filesystem Handling to Work With Reference Points (roadblock 1)
  3. Cleaning Up Old Project/Module Specific Logic
  4. Implementing a Proper Handling for Binary Files (roadblock 3)
    1. Adjusting the 'IFile' Interface
    2. Adjusting the Consistency Watchdog
    3. Adjust IntelliJ Handling for Opening Non-Binary Files
  5. Implementing a Bridge Component Handling Content Normalization (roadblock 2)
    1. Create Normalization Bridge in Core
    2. Adjust Initial Content Sharing Logic to Use File Content for Non-Binary Files
    3. Adjust Handling of Initial Content During File Creation
    4. Adjust Handling of Recovery Content for Non-Binary Files
    5. (Optional) Handle Corner Cases Where Encoding and/or Line Ending Matters
  6. Implementing a New System to Determine What Not to Share (roadblock 4)
    1. Introduce a Framework to Set Which Resources Should Not Be Shared
    2. Adjust Existing Logic to Offer Excluded/Derived Resource Settings for New Framework
    3. Introduce a Base Implementation Using a '.sarosignore' file
    4. Remove the Old IDE-Dependent Logic
    5. (Optional) Offer '.gitignore' Integration
  7. Handling Miscellaneous Issues
    1. Fix BOM Handling
    2. Implement Unified Handling of Binary Editors

Step 1 – Preparation for the Filesystem Handling Refactoring

The refactoring of the filesystem handling will be a very complex process. To make it easier, there are certain steps that can be taken beforehand to make it a bit easier.

Step 1.1 – Removal of the Partial Sharing Logic

Saros supports what it calls "partial sharing". This feature allows the user to select an arbitrary subset of resources from the current workspace to share.

This feature is only supported by Saros/E and currently broken when used with anything but the most basic setups. The issue with this feature is that it allows the user to choose arbitrary subsets, meaning the resulting structure does not have to resemble a tree. A user could, for example, choose to share a tree, but in that tree to exclude a sub-tree, but in that sub-tree to re-include a sub-sub-tree.

As such arbitrary subsets make the logic very complicated and are most likely the cause for the current faults in the logic. Furthermore, they most likely don't represent a typical use case of a normal user.

With the upcoming introduction of the sharing of reference points, the main feature of partial sharing, allowing the user to share a number of complete (sub-)trees of the workspace, will be available anyways. As this makes the partial sharing feature almost completely obsolete (at least the working parts), the Saros team decide that it can be removed.

As already mentioned, the partial sharing feature makes the core and IDE logic dealing with the filesystem much more complex. Therefore, its removal should reduce the complexity of the core refactoring and make it more manageable.

Step 1.2 – Extraction of Core Components That Need to Resolve Project Resources

As Oliver Hanßen discovered during his work on the filesystem refactoring (see related work), there are some components currently located in the Saros core that still require the functionality to resolve the resources of a shared project. As a result, these components would also need equivalent capabilities for reference points after the refactoring.

To avoid having to offer this functionality in the core, such components should be replaces with just an interface specifying the needed methods located in the core. The needed functionality backing the interface can then be supplied by the individual IDE implementations using the PicoContainer.

This is at least necessary for the FileListFactory, which is used to create a list of all files and their checksum in the local shared context in order to allow Saros to compare initial content differences during the project negotiation.

Step 2 – Refactoring the Filesystem Handling to Work With Reference Points

In this step, the roadblock 1 is resolved.

As this refactoring will be a very complicated process, I don't have a concrete plan on how to tackle it just yet. From what I have learned from Oliver Hanßen's thesis, the approach of starting with the core and moving outwards seems sensible.

The process will most likely also include a bridge component that can be used to map the two different concepts while the refactoring is still ongoing.

But, in contrast to the method applied by Hanßen, I will try to create the border/bridge between the refactored and non-refactored content outside the core boundaries to allow for a cleaned up core as soon as possible. Furthermore, I will try to completely remove the logic mapping reference points to real resources from the core. The groundwork for this should have been done at this point as part of the preparation for this step (see step 2).

Step 3 – Cleaning Up Old Project/Module Specific Logic

After the new way of sharing resources (using reference points instead of projects/modules) has been introduced, there will be a lot of additional logic that will no longer be needed/used. This will mostly apply to the logic handling the creation of projects/modules as part of the negotiation, which can no longer be supported due to difficulties during cross-IDE sessions (as explained in roadblock 1).

Such logic should be removed to clean up the code base. Subsequently, the UI options relying on this logic should be disabled or removed.

Subsequently, the UI needs to be adjusted to the new way of sharing resources (i.e. allowing the user to choose reference points instead of projects).

The general cleanup of old logic will also be done as part of the other steps as necessary.

Step 4 – Implementing a Proper Handling for Binary Files

Note: This step still needs some adjusting to new findings and is currently being worked on.

In this step, the roadblock 3 is resolved.

This step was chosen to be done first as it is a general task that should be finished relatively quickly. Furthermore, it can be worked on independently to the following tasks, meaning I don't have to worry about restrictions.

4.1 Adjusting the 'IFile' Interface

To implement a handling for binary files, I am planing to first introduce a method 'isBinary()' to the 'IFile' interface.

I first though about backing this interface method using the matching IDE-implementation logic. The issue with this approach is that different IDEs might not agree which files are binary and which are not, which would require us to implement a negotiation process creating a maximal list of binary resources for all participants (that is updated every time a user joins the session).

To avoid this and create a unified detection of binary files, we either need to implement our own heuristic (most likely based on checking for null bytes in the first n bytes of the file) or use an external library.

Using an external library seems like a better option as it might provide a better detection than our basic heuristic could and reduces the amount of new code introduced to our repository that we have to maintain.

Update: After some consideration, I decided to use the provided IDE logic instead.

This decision was made as I could not find a library providing the necessary logic or a good approach to implement such logic myself. Any mentioned solutions largely rely on heuristics based on certain bytes (e.g. null bytes). I am, however, not certain how reliable that heuristic is. Furthermore, it would require a separate handling for certain encodings, especially ones that use BOMs.

So to avoid these issues, I decided to use the IDE-specific logic instead. The above mentioned issues of different IDEs having different understandings of which files are binary still exist but should be edge cases. In cases where such differences exist for files that are supposed to be editable as part of the Saros session, at least one party has a misconfigured IDE that would not be able to correctly work on the corresponding files anyways. So it is up to the user to correctly configure the IDE in such cases.

If such cases occur during a session, the local integrity should be preserved at the cost of the session integrity. This is more discussed in step 5.2, 5.3, and 5.4 that deals with the adjustment of the sharing of non-binary file content.

4.2 Adjusting the Consistency Watchdog

Following the introduction of the 'isBinary()' method, the handling of the consistency watchdog (the component checking whether shared files of all participants are still in sync) should be adjusted to the new binary handling.

Currently, the watchdog tries to use the document contents (i.e. what is displayed in the editor) for all files. This is not possible for all IDEs as you can't always access the document view for all file types. IntelliJ IDE, for example, does not allow opening documents for binary files (most likely due to their document content normalization logic described in roadblock 2).

To avoid such issues, the consistency watchdog should instead use the content on disk of binary files.

Step 4.3 – Adjust IntelliJ Handling for Opening Non-Binary Files

As IntelliJ has a strict handling of binary files, it does not allow the user to open an editor for a file for which it does not know the associated file type (e.g. because there is no file extension or the file extension is not recognized by the IDE). If the user tries to open such a file, IntelliJ will first query them on what file type to use.

This, however, leads to issues in Saros sessions if there is an associated file type for a file for one participant but no associated file type for another participant. When the watchdog tries to query the document content on the side of the non-associated participant, it will not receive any valid data, leading to a perceived desynchronization.

This issue is also described in the Saros GitHub issue #683 and PR #748.

To resolve this issue, the best solution would be treat every file without a valid file type association that we determine to be non-binary as a basic text file. This will allow us to access the document content and open editors if necessary.

If the user still wants to access additional features such as syntax highlighting, they can then still set the correct file type after the fact.

Step 5 – Implementing a Bridge Component Handling Content Normalization

In this step, the roadblock 2 is resolved.

Step 5.1 – Create Normalization Bridge in Core

This bridge will be used to convert the content provided by the IDE to a normalized format and transform incoming content back into the local format. What exactly this format will be still has to be determined. One feasible approach would be to simply use the format also used by IntelliJ (UNIX line endings and Unicode charset).

The bridge component should be used to transform the content before it is passed to the internal Saros handling to allow for a unified handling in the core. Otherwise, we would also have to adjust the more complicated algorithms dealing with content synchronization (e.g. the jupiter algorithm). This would have the potential to introduce a lot of faults into a critical system as such adjustments will be relatively complex, which is why they should be avoided.

The logic implementing the normalization bridge also has to adjust the given offsets according to the transformation. This is due to potential differences in line endings which can lead to different offsets (as UNIX and Mac line endings are one character long and Windows line endings are two characters long).

Update: Offset normalization is a somewhat time-consuming process as it requires scanning the entire file content up to the offsets for line ending characters to calculate the corrected offset. This calculation would have to be done every time a selection event is send or received, meaning it would create quite a large performance overhead.

To avoid this overhead, it would be better to adjust the offset implementation. Currently, the offset and length of the selection is used (modeled after the Eclipse API). A better solution for our new requirements would be to instead use the line number and in-line offset for the start and end of the selection. The IDE should provide an API to calculate the needed local offsets from these parameters, meaning the integration of the annotation logic would not have to be adjusted. Using these new values to define a selected field allows us to completely ignore line endings, thereby making the offset correction unnecessary.

This also requires the adjustment of the core logic determining how to handle shared text operations as they are also offset/length based. This requires deeper knowledge of this part of the logic dealing with the jupiter algorithm and operational transformations, which still has to be obtained as part of this thesis.

The logic is modeled after two papers:

Step 5.2 – Adjust Initial Content Sharing Logic to Use File Content for Non-Binary Files

With the current implementation, the initial content of the shared resources is compared and transferred on a on-disc basis. As a result, if a participant joining the session had different on-disc content (i.e. the checksum of the bytes representing the file on disk did not match the one of the host), the content would be overwritten with the bytes of the host. This would even be the case if the actual textual content of the files (i.e. what is displayed in the IDE) were equivalent (e.g. because a different encoding was used, leading to a different binary encoding of the same content).

A further problem is that, even though the encoding is theoretically available for such operations (it is actually not even provided for Saros/E, but that is a separate issue), it is not used for the file creation. Instead, the logic relies on the default encoding set for the project. This is currently generally not an issue for Saros/E as the project settings (i.e. which encodings are used) are also shared by default (i.e. the client's settings will be overwritten by the host's settings), meaning the encoding should generally match (but not in all cases, see issue #774). As a result, this handling will lead to issues if the default encodings of the participants do not match.

In general, this handling does not match the new handling in the rest of Saros that now operates on normalized data. In combination with the changes made to differentiate between binary and non-binary files, Saros can handle non-binary files differently by transferring the document content instead of the bytes on disc. The receiving party can then decide what encoding to use. By default, Saros will most likely use the project default encoding. But, as it operates on normalized content, changing the encoding during a session should also not be a problem.

During the adjustment of the initial content sharing logic, the case that the two Saros clients have a different understanding of which files are non-binary has to be handled. In such cases, the main priority has to be keeping the local integrity in tact.

Step 5.3 – Adjust Handling of Initial Content During File Creation

Similar to the previously mentioned issue with the handling of initial content during the session negotiation, the handling of the initial file content for files created during a session needs to be adjusted as well. The same solution approach applies: Replace the transferal of the binary content for non-binary files with the actual document content.

Step 5.4 – Adjust Handling of Recovery Content for Non-Binary Files

When recovering a file, currently, the binary content is used to re-create the file. This should also be handled according to the new document content handling, i.e. the document contents should be used to set the new content for the recovered file.

Step 5.5 – (Optional) Handle Corner Cases Where Encoding and/or Line Ending Matters

There might be some situations where a specific file encoding or line ending scheme (which doesn't match the project default) is needed for certain files. Such cases would not be handled correctly with the above described handling. Even is the settings were correctly applied on the creator's side, due to the content normalization, they would be lost on the receiver's side.

This is a general issue that is based on the fact that we don't have a good way of telling which files fall into this special category.

One blanket solution approach would be to have fields that can be used to actually enforce an encoding/line ending scheme on the receiving side. These fields could, for example, be used when the settings for the created file do not match the project default. I am, however, not certain how useful this approach would actually be, so this topic has to be further investigated before any time is invested into implementing it.

Step 6 – Implementing a New System to Determine What Not to Share

In this step, the roadblock 4 is resolved.

Step 6.1 – Introduce a Framework to Set Which Resources Should Not Be Shared

This framework will offer a general interface for which different implementations can be provided to support different ways of specifying which resources should not be shared. This allows us to start with a small set of implementations and build support for other tools (preferably with the help of the requesting party) as necessary.

This new functionality will also require an adjustment of the sharing UI as it will require the user to pick what way of determining non-shared files will be used.

Furthermore, an infrastructure to share the settings determined by the host with the other clients will have to be implemented in case their local settings differ from the host or are not present yet at the time of negotiation. But this can easily be achieved by including this data in the initially shared project data.

Step 6.2 – Adjust Existing Logic to Offer Excluded/Derived Resource Settings for New Framework

As the host decides what not to share, offering the option to use the set of locally derived/excluded resources is still a valid approach. As the backing logic already exists, implementing this option should be trivial.

Step 6.3 – Introduce a Base Implementation Using a '.sarosignore' file

Design wise, to keep the syntax as general and as easy as possible, I would like design it strictly after the '.gitignore' file as git is already a widely known/used tool.

Theoretically, we could also just always use .gitignore files by default instead of providing a different file as the syntax will be the same. However, providing a separate file format is important in my opinion as it still allows users to easily exclude resources without using a version control specific file (like a '.gitignore' file), e.g. in case the set of excluded files for the VCS differs from the set of non-shared files for Saros.

Step 6.4 – Remove the Old IDE-Dependent Logic

As it will no longer be needed at this point, the old logic to determine which resources are ignored (i.e. derived/excluded) and its usage in the Saros logic should be removed and replaced with the integration of the new system.

Step 6.5 – (Optional) Offer '.gitignore' Integration

It would be nice to already offer an integration for git as it is currently one of the most widely used VCS. Furthermore, as our base logic used for the '.sarosignore' file is based on git, providing this integration should not take much effort.

Step 7 – Handling Miscellaneous Issues

This section contains miscellaneous issues that were found during the design/implementation phase which should be resolved but aren't critical for the process of providing IDE cross-compatibility capabilities for Saros.

Step 7.1 – Fix BOM Handling

IntelliJ does not include the BOM (byte order marker) when reading file contents. This is an issue as it is included in when reading such files through the Eclipse API. This problem is also discussed in issue #707.

To avoid this issue, a general handling of BOMs need to be implemented for Saros. Either the BOM needs to be handled separately in all cases if present (i.e. the output would need to be split in the Saros/E API) or it needs to be included in the content in all cases if present (i.e. it needs to be prepended to the main content in the Saros/I API).

Step 7.2 – Implement Unified Handling of Binary Editors

Binary editors should be handled the same way by all Saros implementations. Currently, Saros/E completely ignores binary files/editors during a session. Saros/I, on the other hand, tries to handle them like normal editors. (The handling is currently broken, see step 1.3.)

Also handling binary editors would allow us to include them in the follow mode, meaning other participants would also open the editor for the binary file when the followed participant does.

Furthermore, a handling of binary files for the watchdog has to be determined. If binary files are always ignored, we don't have to include them in the watchdog handling as the watchdog only looks at files that are detected as "open". However, if they are not ignored, there might be some value in also checking binary file consistency in case a user has modified a binary file (in whatever way) without us noticing.


Work Log

Preparation

Activities

I also looked for general articles about the usability of (distributed) pair programming tools but was not able to find many sources that brought new information to the table. Most of the important information is already given in the dissertation from Julia Schenk (which also references the sources it uses).

Week 00 + 01 (CW 03+04)

currently working on milestone 1

Activities

  • skimmed through Saros codebase
  • created preliminary list of roadblocks (see milestone 1)
  • requested feedback on Saros developer mailing list
    • working together with other developers is very important to design something that can actually be integrated into the codebase
    • asking for help from developers with in-depth knowledge of the Saros/E codebase to figure out implementation specific differences between Saros/E and Saros/I
  • looked ad VSCode API to gather information about internal workings and possible compatibility issues
    • so far unsuccessful as API documentation is ok but there is no documentation about base concepts/assumptions

Results

  • updated list of roadblocks on this page

Next Steps

  • discussing the list of preliminary roadblocks with other Saros developers

Problems

Week 02 (CW 05)

currently working on milestone 1 and 2

Activities

  • discussed cross-compatibility issues with other Saros developers on separate occasions (Stefan and Kelvin)
  • decided to remove the milestone 2 "The basic design for Saros IDE cross-compatibility is complete" from the agenda as it is too general
    • the basics are already covered by the list of roadblocks
    • any other issues that may arise on the way to IDE cross-compatibility will most likely be very IDE implementation dependent, meaning they are hard to foresee
  • created an initial plan on how to proceed implementing solutions for the found roadblocks (see milestone 2)
    • added detailed description for every step of the plan describing what has to be done and some of the though behind the step
  • found additional roadblock 4
  • cleared up general design of future Saros architecture
    • as shown by the difficulties caused by a lack of such a general overview, specifying the desired architecture might still be necessary/useful after all
  • cleared up misconception about difficulties dealing with normalized encodings
    • as we are sharing document content changes by using their String representation, the content was already normalized to using Unicode characters
    • this removes the need to care about the conversion ourselves, the only remaining issue is what to do on remote file creation
  • searching for a good way of determining whether a file is binary or not

Results

  • finalized initial list of roadblocks
  • created list of steps on the way to IDE cross-compatibility
  • improved planned design of new Saros architecture

Next Steps

  • start implementing?

Problems

  • scope of thesis/feature set of Saros is still not completely clear
    • this is most likely due to the missing user feedback and knowledge what the general use case for Saros should be
  • did not have a clear view of the desired Saros architecture, leading to issues while planning/designing the adjustment of Saros for IDE cross-compatibility
  • wanting to please all possible users/cover all use cases is nearly impossible in this scenario and at least not feasible in the scope of this thesis
    • making the decision of cutting features/use cases is hard without a good knowledge of the user base or desired use case
  • determining whether or not a file is binary is quite complicated

Week 03 (CW 06)

*currently working on milestone 2

Activities

  • changed stance on binary handling to use IDE logic
    • could not find library handling detection of binary files
    • implementing logic myself seems like to much work (as there are many corner cases) and still requires to much guess work to be reliable
    • IDE logic should be usable in most cases as misconfiguration would also mean that the file can not be worked on in IDE
  • updated step 1 to reflect new plan
  • adjusted step 5 to also include the adjustment of the recovery logic
  • adjusted step 5 to include more details regarding the handling of mismatched binary detection
  • re-added the option of using locally excluded/derived resources of the host to determine what not to share
  • implemented adjustment needed for step 1 but was stopped by architectural questions:
    • how should we handle editors for binary files?
  • skimmed over code to get a basic idea on how to implement the logic needed for step 5
  • started writing basic "design" for Saros (i.e. what should be able to Saros do, what are its core capabilities)
  • implemented prototype normalization bridge
    • noticed likely performance problems as a result of having to read the entire text up to the offsets for offset correction when sending and receiving selection activities
    • better solution would be to switch activities to sending line and in-line offset instead of global offset; allows to skip offset normalization

Results

  • created initial list of steps to take (see milestone 2)
  • developed initial prototype ideas for different steps and discovered issues with some of the steps
  • created initial feature set/design for Saros

Next Steps

  • discuss "feature set"
  • re-work initial list of steps

Problems

Week 04 (CW 07)

currently working on milestone 2

Activities

  • prepared and held initial presentation
  • further discussed handling of encodings and line endings
    • reached consensus that encoding should be determined by creator of resource, line endings by local IDE settings (i.e. follow git handling)

Results

  • presentation (see slides)
  • noticed (during presentation discussion) that offset correction also needs to apply to text operations
    • see Problems section for more on this

Next Steps

Problems

  • offset correction for text operations means that the Jupiter algorithm and operational transformation logic in the core needs to be adjusted as well
    • hoped that this could be avoided as they are important parts of the logic, very complex, and not that well understood by the current developers in the project (myself very much included)

Week 05 (CW 08)

currently working on milestone 2

Activities

  • looked at Saros Core concurrency implementation
    • checked usage of operation position to ensure move to new position scheme (line number + in-line offset) is plausible
  • read base literature on Jupiter algorithm: "High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System"
  • finished planning process for list of steps
  • started working on unifying handling of non-text editors for Saros/E and Saros/I

Results

  • improved understanding of Jupiter algorithm design and our implementation
  • ensured adjustment of position scheme (line number + in-line offset) is compatible with the Jupiter algorithm
  • adjusted list of steps

Next Steps

  • start implementing steps

Problems

Week 06 (CW 09)

currently working on milestone 2 & 3

Activities

  • worked on unifying handling of non-text editors for Saros/E and Saros/I
  • did testing on non-binary vs. opened in non-text editor (see Problems)
  • started working on migration of offset based activities to position based activities
    • started with selection annotations
    • encountered problems with being reliant on editor to make conversion (see Problems)

Results

  • created PR #842
  • decided to stick to line based selection model
    • will implement caching of line number <-> offset mapping if performance becomes an issue
  • created initial prototype for selection handling migration to position based logic
  • refined initial prototype to make it ready to be proposed as a PR

Next Steps

  • get PR #842 reviewed and merged
  • create PR for selection refactoring

Problems

  • discovered that the concepts of binary and not openable in a text editor are not the same thing
    • e.g. class files are opened in a text editor for IntelliJ
  • local logic calculating line number <-> offset needs editor
    • if no editor is present, requires manual calculation
    • can be sped up by caching offset <-> line number mapping, but this requires a lot of additional logic and requirements to the base logic (i.e. activities need to be processed linearly, even selection and text edits)
  • handling of base logic in Saros/E and Saros/I is more different than initially thought
    • handling of background changes without an open editor
    • handling of file moves/renames and the handling of caused text changes

Week 07 (CW 10)

currently working on milestone 3

Activities

  • refined initial prototype for moving to a line base selection model
  • improved PR #862 according to review comments
    • decided to not merge the PR until at least the prototype for the text edit handling is complete, meaning the approach of using the new positioning scheme is valid
  • worked on prototype for refactoring the text edit handling to use the new positioning scheme
    • adjusted initial design by shifting to a line delta and offset delta model for operations
    • operation is defined through start position, line delta, offset delta, and text
    • makes it easy to calculate end positions on the fly, even with changing start positions
    • offsets could always be calculated from text on the fly, but this would be time intensive and would require us knowing the used line separator (or guess it)
  • found issue in split operation combination handling

Results

  • created PR #862 refactoring the selection handling
  • rough prototype for text edit activity refactoring is done
    • smoke test pass (starting a session in Saros/I or Saros/E and editing shared text)
    • started adjusting tests
      • so far, all tests passed without having to adjust the setup (have not gotten to the important GOTOInclusionTransformationTests, so this does not say much so far)
  • created PR #868 to fix issue in split operation combination handling

Next Steps

  • need to think about good sanity check for calculated selection positions
    • selections are not handled by the Jupiter algorithm, meaning the base document can change without the selections being adjusted
    • therefore, the conversion offset <-> text position might fail or the result might no longer be applicable to the base document
    • such no longer valid selections should preferably be filtered out silently
  • continue working on text edit activity migration to new positioning scheme

Problems

  • refactoring of text edit activities is more complex than initially thought
    • initial approach of using start, new end, and old end position can be used for text edit activities but not for operations
    • operations are often transformed and shifted, meaning the end positions aren't useful
    • resolved by moving to line delta and offset delta handling

Week 08 (CW 11)

currently working on milestone 3

Activities

  • worked on prototype for refactoring the text edit handling to use the new positioning scheme
  • migrated all existing tests for text activities, the Jupiter algorithm, operational transformations, and split operations
    • all tests and STF test pass
  • worked on refining the prototype to create an actual PR
  • finished base version of refactoring of text edit activity
    • migrated logic and tests
    • still need to extend test suite to cover new cases added with migration
  • improved selection refactoring PR #862

Results

  • created test suite for API added in PR #862
  • created PR #872 for text edit activity migration
  • merged PR #842
  • added missing base cases not covered by the previous test suite for SplitOperation and GOTOInclusionTransformation
  • added more complex multi-line test cases for SplitOperation
  • added more complex multi-line test cases for inclusion transformation
  • debugged inclusion transformation
  • finished work on PR #872 so that it is ready for review

Next Steps

  • get PR #862 and PR #872 reviewed and merged
  • start working on content normalization

Problems

Week 09 (CW 12)

currently working on milestone 3

Activities

  • improved PR #872 according to review suggestions
  • improved PR #862 according to review suggestions
  • implemented fuzzer for inclusion transformation
  • implemented content normalization for text edit activities
  • implemented content normalization for the consistency watchdog checksum generation
  • improved PR #877 according to review suggestions
  • started working on preparing the migration to using reference points
    • started working on removing partial sharing
      • worked on removing access to partial sharing feature from UI

Results

  • created PR #874 which adds an inclusion transformation fuzzer
  • created PR #877 which adds content normalization for text edit activities
  • created PR #878 which adds content normalization for the consistency watchdog checksum generation
  • addressed review comments on existing PRs
  • decided to stop working on content normalization for now
    • current normalization is sufficient for an IDE cross-compatibility session
    • remaining work rather offers a better user experiences and removes some weird behavior in edge cases
    • there are more pressing issues that need to be addressed first
    • -> moved on to working on reference point refactoring
  • created PR #880 removing access to the partial sharing feature from the Eclipse UI

Next Steps

  • work on removing partial sharing

Problems

  • partial sharing logic is not very well separated from the normal sharing logic, meaning removing it takes a lot of manual searching and adjusting of logic

Week 10 (CW 13)

currently working on milestone 3

Activities

  • worked on removing partial sharing
  • started thinking about design for reference point model
  • discussed possible implementations for a new filesystem model

Results

  • created PR #882 removing the partial sharing logic
  • addressed review comments on existing PRs
  • decided to postpone work on filesystem overhaul for now and instead work the new exclusion logic

Next Steps

  • implement new exclusion logic

Problems

  • how to deal with extending the scope of partial sharing
    • issue if the extension of the scope leads to overlapping reference points, i.e. a reference point higher in the tree is chosen
  • unclear what the actual use cases of Saros are/should be
    • don't think using Saros to only share a partial tree with a participant not having the whole project is sensible
      • task is more suited to screen sharing/remote desktop or the sharing done by VSCode (mirroring local IDE to other side)
      • missing context of project will severely restrict IDE functionality (like looking up resources, library usages, language features, etc.)
    • sharing whole project with user who initially has nothing only plausible without IDE integration with cross-IDE sharing
      • not guaranteed that needed configuration files exist locally (see Saros; Eclipse files need to be generated) * not possible (to my knowledge) to in-place reload the correct project setup after adding the initial, general setup in Eclipse (i.e. always causes resource doubling, one contained in the initial, general project, the other contained in the correct projects loaded afterwards)

Week 11 (CW 14)

currently working on milestone 3

Activities

  • worked on implementing new exclusion logic
  • had discussion about new resource implementation
  • merged existing PRs

Results

Next Steps

  • design and implement the new resource handling

Problems

  • resource - ID mapping is hard to integrate as there are multiple components that rely on its timeliness
    • need to ensure that mapping is updated in time on file creations and is not updated too soon on file deletions
  • encountered unhandled corner cases that lead to additional issues with new resource - ID mapping
    • simultaneous creation of the same resource by different participants (additionally with different initial content)
    • simultaneous move of the same resource (additionally to different locations)

Week 12 (CW 15)

currently working on milestone 3

Activities

  • worked in design for new resource implementation
  • fixed issue with Saros/I annotation logic
  • prepared Saros/I release 0.3.0

Results

  • created PR #900 fixing an issue with the Saros/I annotation logic
  • created PR #901 preparing for the Saros/I release 0.3.0

Next Steps

  • work on new resource implementation

Problems

  • not as trivial as initially thought to define a simple resource model

Week 13 (CW 16)

currently working on milestone 3 (now actually)

Activities

  • worked on cleaning up resource interface before beginning working on new resource implementation
    • working through existing interfaces gave me good overview of current logic/implementation
    • simplifying and unifying the interface and its implementation will make the introduction of a new resource system easier
  • worked on improving charset handling

Results

  • created PR #905 fixing an IDE cross-compatibility issue with the Saros/I file move logic
  • created PR #906 removing the IResurce.move(...) method
    • abstraction makes edge cases where resources are moved to a different project/module more difficult to handle
    • as logic was never used in the core, it was not worth it to keep such an abstraction
    • moving the logic to the IDE implementations offers the possibility of optimizing it for the specific IDE resource logic it is working with
  • created PR #907 simplifying the resource interfaces IResource, IContainer, IFile, and IFolder
  • created PR #908 simplifying the resource types defined in IResource
  • merged PR #905, PR #906, PR #907, and PR #908
  • created PR #913 adjusting the handling of received file activities to set the charset for created files
  • created PR #914 adjusting Saros/E to always send the charset for file activities if necessary and requiring file activities to contain a charset if they contain binary content
  • created PR #915 removing IContainer.getDefaultEncoding()
  • created PR #916 removing IResource.adaptTo() and replacing its usage with simply casting the objects
  • created PR #918 removing FolderMoveActivity as it was no longer being uses

Next Steps

  • improve SPath abstraction/usage

Problems

Week 13 (CW 17)

currently working on milestone 3 (now actually)

Activities

  • worked on replacing SPath in resource activities
  • worked on completely removing the usage of SPath
  • continued cleanup of resource interfaces

Results

  • created PR #934 removing the usage of SPath from the resource activity implementations
  • created PR #938 completely removing SPath
  • created PR #943 removing IProject.findMember(IPath) as it was no longer being used

Next Steps

  • continue cleanup of resource interfaces
  • think about which abstraction level to use for the Eclipse implementation

Problems

Week 14 (CW 18)

currently working on milestone 3 (now actually)

Activities

Results

  • created PR #950 removing IWorkspaceRoot as it was not being used in the core
  • created PR #952 moving the remaining methods of IProject into IContainer
    • this was done as a preparation for the move to reference points, which are basically all just containers in the eyes of Saros
  • created PR #953 removing the methods IResource.getLocation() and getFullPath() to consolidate the path handling of resources to only use getProjectRelativePath()
  • (worked on Saros/I caret handling)

Next Steps

  • start with actual resource interface rework

Problems

Week 15 (CW 19)

currently working on milestone 3 (now actually)

Activities

  • (finished work on Saros/I caret annotations)

Results

Next Steps

  • continue planing new resource implementation and start reworking the IDE-specific implementations

Problems

Week 16 (CW 20)

currently working on milestone 3 (now actually)

Activities

  • (continued working on release 0.3.0)
  • worked on further cleanup for resource interfaces
  • reworked javadoc for resource interfaces
  • worked on migrating Saros/I to a reference point resource model
  • created prototype reference point based resource implementation for Saros/E

Results

  • created and merged PR #972 fixing an issue with the Java 11 build of Saros
  • create PR #981 fixing the handling of empty selections
  • created and merged PR #982 fixing a regression issue causing editors to open for newly created files during the project negotiation
  • created PR #976 cleaning up the IWorkspace interface
  • created PR #977 adding javadoc to the resource interfaces
  • created PR #978 overwriting IProject methods where the functionality does not match the original parent interfaces defining the method and adds default implementations for methods with constant behavior

Next Steps

  • continue working on Saros/I migration
  • start working on Saros/E migration

Problems

  • not that familiar with the Saros/E code, so the migration for Saros/E might take a lot longer

Week 17 (CW 21)

currently working on milestone 3 (now actually)

Activities

  • (final steps in Saros/I release 0.3.0)
  • worked on migrating Saros/I to a reference point resource model

Results

  • merged PR #981 fixing the handling of empty selections
  • created and merged PR #986 adjusting the version compatibility logic to ignore micro/patch version modifiers.
  • created PR #997 introducing a reference point based resource implementation
  • created PR #998 migrating the Saros/I core logic to use the new reference point resource system
  • created PR #999 migrating the Saros/I UI to support the new reference point resource system
  • created PR #1000 cleaning up after the migration to the new resource system
  • created PR #1001 migrating the logic to handle local resource changes to support the new reference point based resource system

Next Steps

  • get Saros/I migration PRs reviewed
  • clean up references to project based resource system in core
  • migrate Saros/E to reference point based resource system

Problems

Week 18 (CW 22)

currently working on milestone 3

Activities

  • finisher initial work on Saros/I migration
  • cleanup up Saros core

Results

  • created and merged PR #1005 adjusting IContainer.members() to return a list instead of an array
  • created PR #1008 removing references to the "reference point" concept from the Saros/I UI
    • decided to keep this as an internal concept as it might confuse user
    • speak of "shared root resources" in user world as they will probably already be familiar with this concept
  • created PR #1012 cleaning up the Saros core
    • removes references to old sharing system
    • replaces mentions of "projects"
    • renames IProject and related resource methods
  • created PR #1019 removing AdditionalResourceData as it is no longer used

Next Steps

  • work on saros/E migration
  • review and merge Saros/I migration

Problems

Week 19 (CW 23)

currently working on milestone 3

Activities

  • worked on Saros/E migration to reference point resource mode
  • migrated inner classes
  • started working on migrating the UI

Results

  • created PR #1023 adding the new resource implementations

Next Steps

  • migrate Saros/E UI
  • migrate and fix STF tests

Problems

  • UI adjustment is no as easy as thought as Eclipse tree viewer does not allow disabling elements
    • workaround for now is simply dropping illegal user input

Week 20 (CW 24)

currently working on milestone 3

Activities

  • worked on Saros/E UI migration
    • migrated UI to choose resources on sender side
    • fixed minor issues in previous migration steps
    • migrated CollaborationUtils and its callers

Results

Next Steps

  • migrate UI to accept resource negotiations
  • migrate logic for Eclipse UI integrations (i.e. when to show what pop-up/dialog)
  • migrate STF
  • clean up Saros/E after migration

Problems

  • UI is very purpose-build, meaning adjusting/modifying it is very complicated and requires large rewrites
  • parts of UI logic are much more complicated than necessary (i.e. "overbuild") due to feature creep in the past
    • additional logic not always integrated in a great way
    • complicated and time-intensive to migrate

Week 21 (CW 25)

currently working on milestone 3

Activities

  • worked on Saros/E UI migration
  • finished initial work on UI migration
    • migrated UI to accept incoming resource negotiations
    • migrated Eclipse UI integration
    • migrated remaining wording in UI
    • migrated STF to work with new logic
  • worked on debugging STF issues in docker without much success

Results

  • merged PR #1026 allowing for Saros/E remove debugging using IntelliJ IDEA

Next Steps

Problems

Week 22 (CW 26)

currently working on milestone 3

Activities

  • finished Saros/E migration
    • cleaned up Saros/E code base
  • worked on providing better local mapping suggestions for incoming resource negotiations

Results

  • created PRs for the Saros/E migration to the reference-point-base resource model
    • created PR #1032 migrating most internal classes of the Saros/E
    • created PR #1033 migrating the filesystem handlers of Saros/E
    • created PR #1034, PR #1036, and PR #1039 migrating the UI internals of Saros/E
    • created PR #1035 migrating the wizard to select resources to create a resource negotiation with
    • created PR #1037 migrating the wizard to select resources to represent the shared reference points when accepting a resource negotiation
    • created PR #1038 and PR #1049 cleaning up Saros/E after the migration
    • created PR #1040 adjusting the STF after the Saros/E migration
  • created PR #1051 introducing logic to provide better mapping suggestions for incoming resource negotiations (especially for non-project/module directories) that works cross-IDE

Next Steps

  • get open PRs reviewed and adjust for review comments
  • start writing thesis paper

Problems

Week 23 (CW 27)

currently working on writing

Activities

  • worked on writing the thesis
  • worked on review comments for open PRs

Results

  • created PR #1058 adding sanity check for nested reference points to core

Next Steps

Problems

Week 24 (CW 28)

currently working on writing

Activities

  • worked on writing the thesis
  • worked on review comments for open PRs

Results

*

Next Steps

Problems


TEMPLATE

Week N (CW XX)

currently working on milestone X

Activities

  • been there, done that

Results

  • achieved XYZ

Next Steps

  • planning ...

Problems

  • ...

Topic revision: r79 - 30 Aug 2020, TobiasBouschen
 
  • Printable version of this topic (p) Printable version of this topic (p)