# _CoVSCode_: A Novel Real-Time Collaborative Programming Environment for Lightweight IDE
## 2 Related Work
### Problems and Limitations of Existing Real-Time Collaboration Support for Lightweight IDEs  
As introduced above, lightweight IDEs have rapidly grown in popularity in the recent years. However, to the best of our knowledge, there is very limited support for real-time collaboration with lightweight IDEs. The two official real-time collaboration plugins for _Visual Studio Code_ and _Atom_, namely _Visual Studio Live Share_[34] and _Teletype for Atom_[35], are the most sophisticated and mature so far, but they only support a specific collaboration pattern, with major problems and limitations.  
Both _Live Share_ and _Teletype_ have been designed with only one specific collaboration pattern, which can be named as a _host-participator_ pattern: one programmer acts as the _host_, while other programmers act as _participators_. The complete source code copy of the collaboration session is only maintained at the host's local workspace. Whenever a group of programmers start to collaborate, there must be one host who prepares the base of the source code at the local workspace, initializes the collaboration session and then invites others to join. During the collaboration session, each participator may be able to view the source code tree, but the content of any concrete source code file is only transmitted when the participator opens that file. Specifically, with _Teletype_, this is even more constrained--only the host can open/close files, whereas participators can only view and edit files that are currently opened at the host's site. Moreover, for both _Live Share_ and _Teletype_, even after a source code file has been transmitted to the participator's site, it only resides in the memory (but not on the local disk). Such architectural and functional design leads to the following problems and limitations:  
1. Because each source code file is only transmitted from the host to the participator on-demand, the network latency greatly affects the user experience at the participator's site, and when a file is opened, it takes a while to show up, which depends highly on the network condition.
2. The host must preserve an active network connection at all times during the collaboration session. Whenever the host encounters an issue and temporarily loses the network connection, the whole session is terminated, and all ongoing work made by the participators (that have not been transmitted to the host yet) will be lost.
3. At each participator's site, the source code files are incomplete and reside in the memory only, and as a result, there is very limited language support (because many IDE features rely on cross-file or even project-wide knowledge, such as the _\"go to definition\"_ feature).  
4. The debugging feature is commonly not supported at the participators' sites because of the incomplete and memory-residing source code files. Although _Live Share_ is claimed to support collaborative debugging, the program execution actually takes place at the host's site during the debugging process, and no participator can independently debug or test the program without interfering with the host's ongoing work.  
In addition to the major limitations presented above, there are also various minor issues with the two official real-time collaboration plugins. For example, both of them require Internet connections with servers hosted in the cloud, and thus are not suitable for internal development teams with high security concerns.