Software engineers who collaborate to develop soft- ware in teams often have to manually merge changes they made to a module (e.g. a class), because the change conflicts with one that has just been made by another engineer to the same or another module (e.g. a supplier class). This is due to the fact that engineers edit code separately, and loosely coordinate their work via a source control or a software configuration management system (SCM). This work proposes to eliminate almost all the need to manually merge a recent change, by proposing a Collaborative Real Time Coding approach. In this approach, valid changes to the code are seen by others in real time, but intermediate changes (that cause the code not to compile) result in blocking other engineers from making changes related to the entity (e.g. method) being modified, while allowing them to work on most of the system. The subject of collaborative real time editing systems has been studied for the past 20 years. Research in this field has mostly concentrated on collaborative textual and graphical editing. In this work we address the challenges involved in designing a collaborative real time coding system, as well as present the major differences when compared to collaborative editing of plain text. We then present a prototype plug in for the Eclipse Integrated Development Environment ( IDE) that allows for a collaborative coding to take place. Index Terms—Collaborative Real Time Coding; Integrated Development Environment; Software Configuration Management Tools; This paper was written in 2011.
Unlike most other collaborative editing systems, Jupiter @cite_9 implemented a centralized architecture. A central sever was responsible to mediate between any two clients, so that at any given time only 2-way communication could take place (the central server and some client). This server also held the responsibility of propagating changes to all other clients. When the cental server received an operation request, it was transformed, if necessary, and applied to the local document state, followed by propagation to other clients. This centralized manner of communication inherently relieved Jupiter of both the dOPT puzzle and precedence issues. The fact that at any given time only a 2-way synchronization took place alleviated the issue of preserving precedence between operations.
@cite_9
1989814541 15308973 1916848204 1433235304
Jupiter is a multi-user, multimedia virtual world intended to support long-term remote collaboration. In particular, it supports shared documents, shared tools, and, optionally, live audio video communication. Users who program can, with only moderate effort, create new kinds of shared tools using a high-level windowing toolkit; the toolkit provides transparent support for fully-shared widgets by default. This paper describes the low-level communications facilities used by the implementation of the toolkit to enable that support. The state of the Jupiter virtual world, including application code written by users, is stored and (for code) executed in a central server shared by all of the users. This architecture, along with our desire to support multiple client platforms and high-latency networks, led us to a design in which the server and clients communicate in terms of high-level widgets and user events. As in other groupware toolkits, we need a concurrency-control algorithm to maintain common values for all instances of the shared widgets. Our algorithm is derived from a fully distributed, optimistic algorithm developed by Ellis and Gibbs [12]. Jupiter’s centralized architecture allows us to substantially simplify their algorithm. This combination of a centralized architecture and optimistic concurrency control gives us both easy serializability of concurrent update streams and fast response to user actions. The algorithm relies on operation transformations to fix up conflicting messages. The best transformations are not always obvious, though, and several conflicting concerns are involved in choosing them. We present our experience with choosing transformations for our widget set, which includes a text editor, a graphical drawing widget, and a number of simpler widgets such as buttons and sliders. Cloud-based services are an attractive deployment model for user-facing applications like word processing and calendaring. Unlike desktop applications, cloud services allow multiple users to edit shared state concurrently and in real-time, while being scalable, highly available, and globally accessible. Unfortunately, these benefits come at the cost of fully trusting cloud providers with potentially sensitive and important data. To overcome this strict tradeoff, we present SPORC, a generic framework for building a wide variety of collaborative applications with untrusted servers. In SPORC, a server observes only encrypted data and cannot deviate from correct execution without being detected. SPORC allows concurrent, low-latency editing of shared state, permits disconnected operation, and supports dynamic access control even in the presence of concurrency. We demonstrate SPORC's flexibility through two prototype applications: a causally-consistent key-value store and a browser-based collaborative text editor. Conceptually, SPORC illustrates the complementary benefits of operational transformation (OT) and fork* consistency. The former allows SPORC clients to execute concurrent operations without locking and to resolve any resulting conflicts automatically. The latter prevents a misbehaving server from equivocating about the order of operations unless it is willing to fork clients into disjoint sets. Notably, unlike previous systems, SPORC can automatically recover from such malicious forks by leveraging OT's conflict resolution mechanism. Online services distribute and replicate state across geographically diverse data centers and direct user requests to the closest or least loaded site. While effectively ensuring low latency responses, this approach is at odds with maintaining cross-site consistency. We make three contributions to address this tension. First, we propose RedBlue consistency, which enables blue operations to be fast (and eventually consistent) while the remaining red operations are strongly consistent (and slow). Second, to make use of fast operation whenever possible and only resort to strong consistency when needed, we identify conditions delineating when operations can be blue and must be red. Third, we introduce a method that increases the space of potential blue operations by breaking them into separate generator and shadow phases. We built a coordination infrastructure called Gemini that offers RedBlue consistency, and we report on our experience modifying the TPC-W and RUBiS benchmarks and an online social network to use Gemini. Our experimental results show that RedBlue consistency provides substantial performance gains without sacrificing consistency. Distributed storage systems run transactions across machines to ensure serializability. Traditional protocols for distributed transactions are based on two-phase locking (2PL) or optimistic concurrency control (OCC). 2PL serializes transactions as soon as they conflict and OCC resorts to aborts, leaving many opportunities for concurrency on the table. This paper presents ROCOCO, a novel concurrency control protocol for distributed transactions that outperforms 2PL and OCC by allowing more concurrency. ROCOCO executes a transaction as a collection of atomic pieces, each of which commonly involves only a single server. Servers first track dependencies between concurrent transactions without actually executing them. At commit time, a transaction's dependency information is sent to all servers so they can re-order conflicting pieces and execute them in a serializable order. We compare ROCOCO to OCC and 2PL using a scaled TPC-C benchmark. ROCOCO outperforms 2PL and OCC in workloads with varying degrees of contention. When the contention is high, ROCOCO's throughput is 130 and 347 higher than that of 2PL and OCC.