<%BANNER%>

Mother of All Concurrent Editors Version 2.0


PAGE 1

MOTHER OF ALL CONCURRENT EDITORS VERSION 2.0 By VIJAYA RANGADHA M KOMARAGIRI A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2004

PAGE 2

Copyright 2004 by Vijaya Rangadham Komaragiri

PAGE 3

This thesis is dedicated to my parents.

PAGE 4

ACKNOWLEDGMENTS I thank Dr. Richard Newman for his continued cooperation and encouragement during the course of my thesis. I also thank Drs. Shigang Chen and Ye Xia for serving on my committee, and for their valuable comments. I would like to thank all the DCS group members (past and present) for their support and ideas. I specially thank Harsha Pelimuhandiram and Vijay Manian, whose previous work and input to the project helped me immensely. I wish to express my thanks to my family. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iv LIST OF FIGURES.........................................................................................................viii ABSTRACT.......................................................................................................................ix CHAPTER 1 INTRODUCTION........................................................................................................1 1.1 Motivation..........................................................................................................1 1.2 Conclusion.........................................................................................................3 1.3 Thesis.................................................................................................................3 2 COLLABORATION AWARE SOFTWARE..............................................................4 2.1 Introduction........................................................................................................4 2.2 Issues in Collaboration Aware Software............................................................4 2.2.1 Promptness................................................................................................5 2.2.2 Collaboration Distance..............................................................................5 2.2.3 Presenting and Viewing............................................................................5 2.2.4 Seams........................................................................................................6 2.2.5 Social Roles of Collaboration...................................................................6 2.3 Concurrent Editing.............................................................................................6 2.3.1 Concurrency Index and Editable Granularity...........................................7 2.3.2 Update Frequency.....................................................................................7 2.3.3 Update Granularity....................................................................................8 2.4 Design Issues.....................................................................................................8 2.4.1 User Perspective........................................................................................8 2.4.2 Distribution and Replication.....................................................................9 2.4.3 Concurrency Control.................................................................................9 2.5 Issues in Concurrency Control...........................................................................9 2.5.1 Collisions..................................................................................................9 2.5.2 File Consistency......................................................................................10 2.5.3 Serializability..........................................................................................10 2.6 Methods of Concurrency Control....................................................................10 v

PAGE 6

2.7 Architecture......................................................................................................12 2.7.1 Centralized Architectures........................................................................12 2.7.2 Replicated Architectures.........................................................................13 2.7.3 Hybrid Architectures...............................................................................14 2.8 Conclusion.......................................................................................................15 3 OTHER SHARED EDITORS....................................................................................17 3.1 Introduction......................................................................................................17 3.2 GRoup Outline Viewing Editor (GROVE)......................................................17 3.3 Collaborative Editing System (CES)...............................................................19 3.4 Aspects.............................................................................................................20 3.5 Quilt.................................................................................................................20 3.6 Multimedia Editing Environment IRIS............................................................22 3.7 Calliope............................................................................................................22 3.8 Editor PREP.....................................................................................................23 3.9 Flexible JAMM................................................................................................24 3.10 Multi-User Text Editor MUSE........................................................................25 3.11 DistEdit............................................................................................................25 3.12 Collaborative Editor SASSE............................................................................26 3.13 Shared Books...................................................................................................26 3.14 ShrEdit.............................................................................................................27 3.15 NetEdit.............................................................................................................28 3.16 mpEdit..............................................................................................................28 3.17 Mother of All Concurrent Editors Version 1.0................................................29 3.18 Conclusion.......................................................................................................29 4 REQUIREMENTS AND DESIGN............................................................................32 4.1 Introduction......................................................................................................32 4.2 Requirements...................................................................................................33 4.3 Design..............................................................................................................34 4.4 Distributed Conferencing System....................................................................39 4.5 Architecture......................................................................................................39 4.6 Conclusion.......................................................................................................39 5 IMPLEMENTATION.................................................................................................41 5.1 Introduction......................................................................................................41 5.2 Platform and Programming Language.............................................................42 5.3 Modules............................................................................................................42 5.3.1 File Manager...........................................................................................42 5.3.2 Edit Manager...........................................................................................43 5.3.3 Edit Window...........................................................................................45 5.3.4 User Interface..........................................................................................46 5.4 Concurrency Control........................................................................................48 vi

PAGE 7

5.5 Replication and Recovery................................................................................49 5.6 Conclusion.......................................................................................................50 6 CONCLUSION...........................................................................................................52 6.1 Introduction......................................................................................................52 6.2 Conceptual Issues.............................................................................................53 6.2.1 Commenting and Annotation..................................................................53 6.2.2 Access Rights..........................................................................................54 6.2.3 Usage Analysis........................................................................................54 6.3 Design Issues...................................................................................................54 6.3.1 Decision Support.....................................................................................55 6.3.2 Extra Copy Editing.................................................................................55 6.3.3 Replication Strategy................................................................................55 6.4 Future of MACE..............................................................................................55 6.5 Conclusion.......................................................................................................56 LIST OF REFERENCES...................................................................................................57 BIOGRAPHICAL SKETCH.............................................................................................60 vii

PAGE 8

LIST OF FIGURES Figure page 1 Centralized architecture............................................................................................12 2 Fully replicated architecture.....................................................................................13 3 Architecture of DCS.................................................................................................38 4 MACE architecture..................................................................................................43 5 MACE file manager.................................................................................................44 6 MACE edit window.................................................................................................46 viii

PAGE 9

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy MOTHER OF ALL CONCURRENT EDITORS VERSION 2.0 By Vijaya Rangadham Komaragiri August 2004 Chair: Richard E. Newman Major Department: Computer Information Sciences and Engineering The utility and popularity of collaborative applications has been growing in recent years owing to geographically diverse workgroups. Collaborative concurrent text editors are an extremely useful tool in collaborative group work. A number of concurrent text editors have been developed in the past 2 decades. However none qualifies as a full-fledged, synchronous, platform-independent concurrent text editor. Mother of All Concurrent Text Editors Version 2.0 (MACE) is a platform-independent object-oriented distributed program that supports fine-grained concurrent text editing. MACE is a synchronous group editor that provides support for fault tolerance with a reliable recovery mechanism to recover from crashes. Distributed Conferencing System Version 2.0 (DCS) is being developed at the University of Florida under the guidance of Dr. Richard Newman. DCS supports collaborative work among users distributed over diverse geographic locations. MACE is designed as the concurrent editing application of the DCS. MACE runs as a stand-alone ix

PAGE 10

editor independent of DCS, and also as an application to DCS. MACE is implemented using Java, RMI and the interface is designed in Swing. MACE uses a locking-based concurrency control mechanism to avoid collisions between collaborators editing the same document. MACE supports implicit sessions where users editing a particular file are put into the same session automatically by the system. The system is designed to minimize communication overhead between the different user sites. x

PAGE 11

CHAPTER 1 INTRODUCTION 1.1 Motivation The first computers were designed for single users to run single jobs at a time. Traditional single-user systems have given way to more advanced systems with multiple users running multiple jobs on a single machine. More advances in computer networking have enabled interconnection of multiple computers giving us access to remote resources. With these traditional systems, communication between users has taken place in asynchronous fashion (through computer mail, etc.,) however the work done in bringing users together as groups has not been sufficient. Group activities have come to dominate the modern workplace. The group activity may be product development, scientific research, document preparation, administration or just entertainment. In fact, many of the most common multi-user programs available are games. Some of the recent research in the field has concentrated on developing several programs with the intention of bringing users to collaborate more closely. Among these, conferencing systems and shared text editors rank as the most useful programs for collaboration. Collaborative editing of a document is a common task nowadays. Writing groups are often distributed over many locations, because of the globalization of the organizations. Since many writers already use computers for their jobs, providing computer support for the collaborative writing process has been identified as an important goal. A concurrent shared text editor would be a very helpful tool in instructing and 1

PAGE 12

2 demonstrating documents across remote sites. Typical examples of joint production of documents are the co-authoring of research papers, and joint development of software programs among other things. A great many documents are explicitly co-authored, and even when only one author's name appears on the final version, the production of a document is usually a collaborative task. Collaboration can take many forms. For example, different authors of a document can edit the same section at different times, each completing a draft before the next one begins. Alternatively co-authors could edit different sections of a document simultaneously. In the process of co-authoring a document, usually there is an initial meeting in which the outline of the document is planned, and the responsibilities are assigned to individual co-authors [1]. Each co-author works in relative isolation to produce their sections. These individual sections are then assembled into a single complete draft, which is then passed for serial editing of the latest draft. To maintain the consistency of the document, the draft can be edited by only one person at one time. A concurrent editor helps to provide solutions to most of the problems encountered in the above process. With a concurrent editor the authors need not necessarily work in isolation, even before the sections are merged. Turn taking is eliminated and the effort in co-ordination in editing the integrated draft in final stages is greatly reduced. A study conducted at the University of Michigan [2] found that a concurrent editing tool helped the group keep more focused on core issues, waste less time on less important topics, and capture what was said as they went. Issues in developing a concurrent shared editor are many and interesting. Designing and implementing such a system to meet the requirements is a fair challenge. The fact

PAGE 13

3 that few shared editors are readily available (despite their great utility) motivated me to produce a good concurrent text editor. MACE Version 1.0 [1] was developed at the University of Florida a decade ago. My study created an enhanced version, with support for platform independence and reliable recovery. 1.2 Conclusion Group activities and collaborative work have come to increasingly dominate the modern workplace. There is a growing need for a concurrent editor to support such collaborative activities. A great many documents are co-authored, and the use of concurrent editors can eliminate many problems encountered during the process. MACE Version 1.0 was developed at the University of Florida in 1991. My implementation of MACE Version 2.0 is an enhancement of the concept of MACE V 1.0. MACE V 2.0 also supports platform independence and reliable recovery from failures, as enhanced features over Version 1.0. 1.3 Thesis My thesis presents the issues and work that were involved in producing Mother of All Concurrent Editors Version 2.0 (MACE V 2.0). Henceforth, MACE V 2.0 is referred to as MACE. In Chapter 2, the concept and issues of collaboration aware software are briefly discussed. Then issues of concurrent editing are discussed in some detail. In Chapter 3, a discussion on some of the existing shared editors is given in light of the issues discussed in Chapter 2. Chapter 4 gives details of the requirements and design of MACE. In Chapter 5 we look at implementation of the system. Chapter 6 has a critique of the editor and future extensions to MACE.

PAGE 14

CHAPTER 2 COLLABORATION AWARE SOFTWARE 2.1 Introduction Software that supports multiple users in cooperative work is known as collaboration aware software. Computer Supported Cooperative Work (CSCW) is the discipline that deals with the use of computers to support groups of people as they cooperate to achieve their goals. In Chapter 2 we introduce some of the issues in collaboration aware software in general and how these issues affect the design of a collaborative application. Then we introduce some of the terms in concurrent editing to help us analyze the issues in concurrent editing. Issues in concurrent editing and methods of concurrency control are discussed further. Different methods of distribution and replication are discussed. Chapter 2 concludes with a discussion of pros and cons of centralized and distributed architectures for the implementation of a concurrent editor. 2.2 Issues in Collaboration Aware Software Collaboration takes place in real time and over a period of time. For example, a video-conferencing system places a high-demand on real-time collaboration, while co-authoring a document requires persistent control over the document. Therefore, collaboration aware software should be able to control the shared material and the environment. Shared material mainly takes two forms: data and ideas. The distinction is made on the basis of persistence. However ideas may be converted into stored data tangible by 4

PAGE 15

5 computers. Requirements of collaboration aware software are the ability to communicate ideas over a distributed environment. The ability to store ideas in the form of data, and the ability to provide controlled shared access to data. One basic requirement of all collaboration aware software is the ability to handle multiple users. Some of the issues in collaboration aware software are the promptness with which the user sites are kept consistent, the collaboration distance between users, the ways of presentation and viewing, and the social roles of collaboration. We discuss each of these issues in detail below. 2.2.1 Promptness One aim of collaboration aware software is to provide prompt real-time support for communication. Promptness requires every user site to be consistent with the others in the shortest time interval possible. Therefore, support for real-time updates is desired. 2.2.2 Collaboration Distance Collaboration distance [1] is the distance by which two or more collaborators are separated by hardware or software restrictions. In other words, it is the limitation on the intimacy of collaboration permitted by the system. This distance is associated by the issues of granularity with which control of sections of a file can be granted exclusively to one user, by distancing others from using that section. 2.2.3 Presenting and Viewing As the collaborators are physically removed from each other, there should be mechanisms by which the ideas and data are presented at remote sites. The presentation of data at remote site brings up issues in viewing paradigms. There are many paradigms for viewing; the most important of them are What You See Is What I See (WYSIWIS) [3] and What You See Is What I May See (WYSIWIMS) [4]. WYSIWIS supports interaction

PAGE 16

6 where everyone sees the same view of the shared material. A major shortcoming of this method is the lack of privacy to the collaborator as strict WYSISIS outlaws the presence of a private workspace. The other paradigm WYSIWIMS, allows the users to have their own private workspaces, at the same time the viewer is given the option of seeing only what he desires irrespective of changes at remote sites. 2.2.4 Seams The coexistence of private and shared workspaces creates two environments for the user. A seam is an obstacle in switching from one environment to the other. In this, the WYSIWIMS paradigm allows for relatively seamless transition between shared and private workspaces. Reducing the impact of these seams is important as it reduces confusion in users and improves the productivity of the collaboration. 2.2.5 Social Roles of Collaboration Defining the roles and rights of the users in a collaboration is an important task in collaboration [5, 6]. To provide support for social roles becomes an important issue in the development of a collaborative application. There can be many different roles in a collaborative environment to relegate the control of the document in preparation. 2.3 Concurrent Editing Traditional text editors are not collaboration aware. They cater to a single user editing one file at a time. These editors are not provisioned for the possibility of multiple invocations attempting to edit the same file. In a networked file system, some applications lock the entire file for editing in order to open them. This will not allow any other user to open the file for editing until the application releases its lock. Microsoft word locks the file before opening it and any other user can invoke the use of that file only in read-only mode. Some other applications allow multiple invocations of a file but

PAGE 17

7 are not collaboration aware. For example if a file is opened through two invocations using notepad, only the changes made by one editor would affect the final version, the choice of the editor being the most recent commit done by it. In most of the traditional editors, sharing of a file can be achieved by passing it from user to another for edit. When more than one user shares a file simultaneously, handling concurrency becomes an issue to preserve the integrity of the file. We introduce few terms that help us analyze the issues related to concurrent editing. 2.3.1 Concurrency Index and Editable Granularity Concurrency Index (CI) [1] is the maximum number of users who may use a file concurrently. Editable Granularity (EG) [1] is the smallest discrete size of text by which a file can be shared. For a file size F, the relation F F/EG holds. If we partition the file into chunks of size X and distribute among the users, then the editable granularity is X and the concurrency index is less than or equal to F/X. Maximum concurrency is attained when the size of the chunk is 0, which is when each user may use zero or more characters concurrently. However, there are other issues which determine the concurrency index (see section 4.2). 2.3.2 Update Frequency The Update Frequency (UF) is defined as the frequency with which changes are reflected at a remote site. The changes can be reflected at a remote site either in real-time, periodic intervals of time or on events controlled by the users. If a user makes a change and the changes are reflected at the remote site immediately with some network latency, the update is propagated in real-time. If the changes are reflected at a remote site at remote intervals of time, then the update frequency is periodic. If the updates are sent to

PAGE 18

8 the remote site only when the user explicitly requests or sends the update or if there is a commit on an event initiated by other users then the UF is user-controlled. It may seem that a good concurrent editor should have real-time UF, but there are instances when this should not be the case. In many instances, the writer may wish to keep his changes private until he has composed a coherent edition of the text. 2.3.3 Update Granularity Update Granularity (UG) is the amount of text updated at the remote site with each local update. UG can take a range of values from one character to the whole file, and this value can be pre-determined or user-controlled. 2.4 Design Issues Having looked at the terms we now look at some of the design issues of concurrent editing, concurrency and User Perspective. A good concurrent editor minimizes the EG to achieve a maximum CI. Minimizing EG also reduces the collaboration distance. For example, a fine-grained editor with EG of one word separates collaborators only by a word. 2.4.1 User Perspective A good concurrent editor should have the features that provide the user with the ease of use, accessibility and ability to filter remote information. Information on other collaborators such as their identification and their roles or modes of participation, e.g., editing, viewing, inactive modes should be readily available. Users should be able to filter their usage to others. One wishing to see the work of another should be allowed to do so with the consent of the former. The user should not be hindered by the fact that the file is being shared unless necessary. The user should be made aware of the collaboration but should not be taxed by its existence.

PAGE 19

9 2.4.2 Distribution and Replication Collaborative software is generally distributed over a network of computers. The shared file could be in one site, partitioned, partially or fully replicated. Partitioning provides a section of the file to each site. One approach of replication is known as master-slave strategy where the master copy is changed and the updates are propagated to the slave copies. Another approach is the distributed update control strategy where no specific copy is treated as the master. Here, control is provided such that any changes to a copy are reflected consistently in all other copies. 2.4.3 Concurrency Control Concurrency control is the mechanism that ensures the consistency of a text file in a distributed shared edit environment. There are different methods and issues involved in concurrency control. 2.5 Issues in Concurrency Control Some of the basic requirements of any concurrency control mechanism are the avoidance of collisions, maintaining file consistency and ensuring serializability. We look at each of these issues in detail below. 2.5.1 Collisions Control of a concurrent text editor is based on avoidance or resolution of collisions that happen when two or more users try to edit the same portion of the file. Collisions can be resolved by ordering the text that result from concurrent editing, in a coherent manner. The text can be ordered on the basis of time, but this may result in losing the syntactic and semantic validity of the text. Collision avoidance is a more plausible solution in handling concurrent text editing and is generally followed. To avoid collisions, we need to exclude the concurrent updates on the same section of the file.

PAGE 20

10 2.5.2 File Consistency When a distributed editing system has the property of consistency, all sites of the system have identical copies of the text. The system can be temporarily inconsistent during the execution of a transaction. Once the transaction terminates, the system should return to a consistent state [7]. Distributed concurrency control algorithms must ensure that the system is consistent in a concurrent multi-transaction environment. 2.5.3 Serializability Serializability is the most widely accepted correctness criterion for concurrency control algorithms [7]. If each transaction by itself keeps a distributed system consistent, then the simplest way to achieve a consistent system over multiple transactions is to execute them in a serial manner. This method severely minimizes the concurrency index of the system and hence we need to find control mechanisms that serialize only the transactions that collide. 2.6 Methods of Concurrency Control There are three common methods used for concurrency control of shared files: locking, timestamping and optimistic concurrency control [8]. Locking ensures exclusive access to parts of the file to maintain consistency, while timestamping and optimistic concurrency control allow concurrent access to the same part of a file and consistency is ensured at the time of commit to exclude collisions. Locking ensures the serialization of transactions that collide. In locking based concurrency control systems, a file update transaction is enveloped by a lock acquisition and a lock release. No updates by other users are allowed on the same section until the lock is released. This method serializes the colliding transactions in a mutually exclusive manner. The transactions that do not collide may concurrently execute on the same file.

PAGE 21

11 Locking restricts access to a section of the text file to a single user. This guarantees collision avoidance. Unlike locking based algorithms, timestamping algorithms do not maintain serializability by mutual exclusion. They select a priori serialization order and execute transactions accordingly [7]. New transactions are checked for conflicts and the transaction with the most recent timestamp is rejected. To maintain the order, each transaction and the sections of the file are timestamped. For this to be possible, the text file has to be identified by sections. This method imposes restrictions on the editable granularity, as the complexity of timestamping operations increase as the size of timestamped section decreases and number of sections increase. Optimistic concurrency control is based on the assumption that the number of collisions is low. Transactions proceed at remote sites with no regard to collisions. Once the edit is performed, the changes are sent to the remote sites. The changes are committed only if there are no collisions. A major disadvantage with this method is the chance of losing changes. Hence, this method is not suitable for concurrent editing of text files. Another method of concurrency control is to maintain a list of multiple versions. Each update generates a new version leaving the earlier as a history version. This method has binding problem [9]. Each operation has to be bound to a version to ensure multi-version serialization. We have seen that unlike other methods of concurrency control locking ensures that changes made to the file are committed by guaranteeing collision avoidance. The user may lose changes with the timestamping, optimistic concurrency control and multiversioning mechanisms. The above reason combined with the relative simplicity and

PAGE 22

12 accuracy, with which a locking mechanism can be implemented, made us chose the locking based concurrency control for MACE. 2.7 Architecture Distributed systems can be broadly categorized on the basis of process distribution or on the basis of data distribution. Architecture for distributed systems can be centralized architecture or a replicated architecture. As the name implies centralized architectures have a central process controlling access to resources and maintaining the consistency of the file. In distributed architectures on the other hand, the process is distributed across a number of sites. We look at each of these in detail below. 2.7.1 Centralized Architectures Centralized architectures have a single instance of an application running on one machine. This machine is like the server that manages the application and smaller clients at each site to handle the I/O. APPLICATION INPUT PROCESS INPUT PROCESS INPUT PROCESS INPUT SELECTION DISPLAY PROCESS DISPLAY PROCESS DISPLAY PROCESS Figure 1. Centralized architecture

PAGE 23

13 The input from all sites is sent to the server. The output is then broadcast by the application to all the clients. Synchronization of the processes is not an issue with this architecture. There are significant disadvantages of this kind of approach. Since all the input and output is directed towards one machine it may become a bottleneck in the network. These architectures may use up heavy bandwidth and may not be suitable for Wide Area Networks (WANs), where the network bandwidth is usually unpredictable and not always available. 2.7.2 Replicated Architectures The fully replicated architecture runs an instance of the application at each client site. The local input is processed at each site and the output is produced for the user. In most cases the local changes are of no importance to the remote sites. Only the necessary input is multicast to remote sites. DISPLAY PROCESS DISPLAY PROCESS APPLICATION INPUT SELECTION INPUT PROCESS INPUT PROCESS APPLICATION APPLICATION INPUT SELECTION INPUT SELECTION INPUT PROCESS DISPLAY PROCESS Figure 2. Fully replicated architecture

PAGE 24

14 The problem of network saturation at one point is greatly reduced with this method. A significant disadvantage of fully replicated architectures is their inability to run on different hardware architectures. The main disadvantage of replicated architectures is the process synchronization. This imposes a high amount of communication overhead on each of the processes in the system. 2.7.3 Hybrid Architectures Partially replicated architectures can help solve the synchronization problem. While most of the application is replicated as clients at remote sites, a part is centralized as server. By channeling the input through the centralized process, it is possible to solve synchronization by reserving the input order. In the design of such a server, we have to be careful not to inundate the central process with unnecessary time-consuming duties. It is possible to customize the clients to be able to execute on different hardware or software architectures. Another conceivable hybrid architecture is a local cluster of users sharing a centralized server and the collection of clusters together use a replicated architecture [10]. 2.7.4 Open Systems An open system is a system whose processes are modularized and are loosely bound. Hybrid architectures can be built as open systems. Each type of process should consist of a set of layers, modules, or objects that could be replaced by others with little or no resulting effect to the rest of the system. This concept makes it easy to customize the system to user and hardware needs. The goals of MACE design include reduction of the dependence on the network speed. MACE uses hybrid architecture with distributed processes at each client site synchronized by a central process.

PAGE 25

15 2.8 Conclusion Collaboration takes place in real-time as well as over a period of time. Collaboration aware software should be able to control the shared material as well as the environment. Promptness in responding to user requests and minimal collaboration distance are desirable characteristics of collaboration aware software. Collaborative software should provide effective ways for collaborators to present ideas to each other. The impact of seams in switching between shared and private workspaces should be reduced. Collaborative software should also devise ways to provide support to mimic the social roles of the collaborators to the extent possible. A good concurrent editor should ideally have a high concurrency index with a low editable granularity. The update frequency and update granularity of a concurrent editing system should be designed for optimal performance on the network. Concurrency control ensures the consistency of a file being edited in a distributed environment. To ensure the consistency, the concurrency control mechanism should have a way to avoid collisions between the actions of different users and the transactions of individual should be serializable. A locking based concurrency control mechanism ensures that changes made by user are not rolled back as there cannot be any collisions between users. Timestamping and optimistic concurrency mechanisms ensure consistency by rolling back colliding transactions and this may cause users to lose their edits at the time of commit. Centralized architectures have a single instance of application running on one machine. This instance processes the inputs from all sites and broadcasts the output. While this may be advantageous for synchronizing all the processes, it uses heavy network bandwidth in excessive communication. A fully replicated architecture reduces

PAGE 26

16 the amount of network communication but imposes a high amount of communication overhead on each of the individual processes to synchronize. Hybrid architecture can help solve the synchronization problem at the same time distributing the process load across clients. Chapter 3 discusses a few of the existing shared text editors in light of the above issues and evolves a set of desired features for the implementation of MACE.

PAGE 27

CHAPTER 3 OTHER SHARED EDITORS In Chapter 3 we look at some of the existing collaborative editors and analyze each of them. We look at the advantages and disadvantages of some of the popular group editors. 3.1 Introduction A brief discussion of the features and architecture of these editors helps us to define our requirements in Chapter 4. We look at some of the synchronous editors like GROVE, ShrEdit, CES, SASSE, Shared Books, Flexible JAMM, MUSE and Calliope. We also look at some of the asynchronous systems such as PREP, DistEdit and Quilt. In the following sections each of the editors is individually discussed and desirable features are identified. 3.2 GRoup Outline Viewing Editor (GROVE) GROVE [11] is an outline editor that supports real-time concurrent editing. GROVE supports fine-grained access control and allows private items within the context of public information. GROVE was developed at the Microelectronics and Computer Technology Corporation, Austin. A GROVE outline is a recursive structure consisting of structured items. Each item has its own text and can contain sub-items of its own. Each item can be private, public or shared. A user makes an item shared by choosing users who form a sub-group that will be given access rights. Each user displays a view of the outline in a viewport. A view is a subset of the outline to which the user has access and a viewer is a window that displays 17

PAGE 28

18 an outline view. This distinction allows users to share views without sharing the viewers displaying them. Users having write access can do the editing of a shared or public item concurrently. Each user has his non-replicated cursor and is able to edit freely. Updates appear in real-time on views that contain the item. GROVE employs a replicated architecture. Concurrency control within items is achieved through the dOPT algorithm that ensures consistency through out the shared views. dOPT is a totally distributed algorithm that requires no locking of items. The main limitation of GROVE is that each item is constrained to a single line of text. Sharing in GROVE is done at two levels. The outline is first shared item by item through the concept of views. If a user needs privacy to make the changes, he needs to make the item private before editing, which will result in denying read access to others while the item is being edited. The sequence of actions: making an item private, editing and releasing it to public view, is equivalent to locking and releasing. Grove allows multiple users to change an item simultaneously and ensures that they see these changes in the same logical order. It does not use centralization or aborts to ensure global order, optimistically expecting few inconsistent concurrent operations. The viewing paradigm of similar shared views is a relaxed version of WYSIWIS as each user has his own cursor and scroll bar. Update frequency of shared views is real-time and this is a desirable feature in specific circumstances. GROVE is an outline editor and not a concurrent editor. The replicated architecture of GROVE ensures a high-degree of fault tolerance. The dOPT algorithm does not require connection-oriented communication. Therefore GROVE can be implemented over a network supporting datagrams. The totally replicated

PAGE 29

19 architecture relies on broadcasting each change to all the sites putting a high demand on network bandwidth. 3.3 Collaborative Editing System (CES) CES [12, 13] is another group outlining system that supports fine-grained locks, delayed transmission of changes to other users and distributed versions of the document. CES was developed at MIT Cambridge. CES supports collaborative editing of a structured outline whose leaf level nodes are variable length text segments. Each text node in the document is owned by a particular user, who is considered the primary author of the node and resides on the machine of the owner. Secondary copies of the node are cached on other authors' nodes and are kept consistent with the primary copy. Changes made by a user are transmitted to other users only when they are committed. To reduce user overhead, CES supports implicit commit. This option for the user is a useful feature. CES supports 'tickle locks' to ensure that two users do not write to the same node simultaneously. A user locks a node when he first edits it and retains the lock as long as some editing activity occurs. Some other user can take the lock away from the holder if the latter is idle for a certain amount of time. At this point, all changes made by the holder are automatically committed. While this is convenient and useful in case one forgets to release the lock, there may be times when the writer is in the middle trying to compose his edit. Taking the lock away from him limits the ability of the writer by not letting him to compose his edit into a coherent form. Since the file is statically partitioned in CES, the editable granularity of CES is equal to the size of a section. CES does not support real-time updates, its update frequency is periodic.

PAGE 30

20 3.4 Aspects Aspects is a commercial multi-user editing application, which provides multiple modes of editing and a special user interface for explicitly requesting and releasing locks. In Aspects, a special user called moderator creates a conference. Moderator has special access rights. Aspects supports three modes of concurrency control and the moderator determines the one used dynamically. In the free for all mediation mode, locking is at the paragraph level. A user editing a paragraph sees a black bar on the side of it and other users see a grey bar. In the medium mediation mode, access to the complete document is serialized and users use a pen passing mechanism to pass control. A user can be writing, waiting for a pen, or just observing. Pen icons are used to pass control. A user can click on his closed pen icon to request the pen. The users icon starts blinking and turns into a raised hand and the writer's open icon also starts blinking. The writer can click on the 'pen in hand' icon to pass control to the first person waiting. Clicking on a black arrow shows the pen status of the different participants. In the 'full mediation' mode, access to the document is again serialized, but this time the moderator determines who gets the pen next after it has been relinquished. In Aspects, up to 16 people can be present in a conference simultaneously. When the moderator closes the conference, everyone is sent a message informing about the termination. 3.5 Quilt Quilt [14] is a tool for collaborative document production. Quilt is developed at the Bell Labs by Fish and Leland.

PAGE 31

21 Quilt provides annotation, messaging, computer conferencing and notification facilities to support communication and information sharing among the collaborators on a document. Views of a document tailored to individual collaborators or to other of the documents users are provided by Quilt. These views are based on the user's position in the permission hierarchy that represents an extensible set of social roles and communication types. Documents in Quilt consist of a base and nodes linked to it using a hypertext methodology. The nodes are of three types: the base document, which is publicly visible, suggested revisions that may be swapped with paragraphs of the base and text and voice comments. Quilt grants access to the document through a notion of social roles. Users with proper rights may modify the document. Annotations may be attached to the document for commenting the text. Quilt also keeps an activity log that is generated by the system, which helps authors keep track of activities. The text in Quilt is stored independent of any editor format. Therefore standard text editors and other tools can be used in text manipulation. Quilt uses Orion as the underlying system for object storage. Quilt's annotation and messaging system makes it a powerful tool for collaborative co-authoring over a period of time. Annotations help the authors know what the others have done and to scrutinize and comment the document while proof reading anothers work. The interaction through Quilt is asynchronous. It does not support real-time updates or communication. The update frequency is writer controlled. The editable granularity is equal to a node or a paragraph of the base node.

PAGE 32

22 The ability to use any editor is a favorable aspect of Quilt. The Quilt-Orion server is the central point of coordination. Therefore, the system is prone to single point of failure. The modular design of Quilt's architecture should facilitate its enhancement by replacing existing modules with more powerful ones. 3.6 Multimedia Editing Environment IRIS IRIS [15, 16, 17] is a collaborative multi-user multimedia-editing environment. A document in IRIS is a collection of objects (text, graphics, video, bibliographic references, etc.,) with relations between them. The relationships can be seen as a structure on the objects. IRIS supports hierarchical structure trees. The manner in which an IRIS document can be partitioned into content objects is not regulated. The only restriction is that data of different media types have to be stored in different objects. The 'storage layer' of IRIS provides document access and has common interface for applications and is extensible for new content media types. IRIS does not impose any access restrictions for concurrency control but follows optimistic concurrency by following the social protocols instead. Any user can edit any part of the document displayed. 3.7 Calliope Calliope [18] is a shared editor developed at the University of Toronto, Canada. Calliope has six major features that facilitate collaboration: access control, public annotations, private text, external annotations, and unstructured text space and awareness tools. Calliope uses multi-level locking to maintain access control. Calliope allows users to privately edit their text before making the changes public. Calliope provides awareness tools to support awareness of other users actions. Color-coded text reveals which author

PAGE 33

23 wrote which sections of a document while a tele-pointer shows the location of a users mouse. There is a shared scroll bar which allows a person to follow another users view. Calliope uses an unstructured text space away from the main document to allow the users to experiment while writing. For this purpose, Calliope provides a shared scratchpad. Calliope is written in Tcl/Tk, and its main text window is a Tk text widget. 3.8 Editor PREP The PREP editor [5] aids in collaborative document preparation with communication, planning and organized annotation. PREP was developed at the Carnegie Mellon University. The system defines chunks that may contain text, ideas or trees that are linked as in hypermedia systems. Chunks are shared among collaborators. PREP allows authors to define 'drafts' that they may intend others to access. The visual interface uses visual cues such as different font sizes and spatial relationships to show the interconnections among chunks. In co-authoring, one author edits a draft and gives a copy to another for reviewing it while the first author incorporates new changes. The PREP editor aids this process by allowing revisions to exist as distinct versions of the draft. It is presently implemented only on MAC. PREP is not a fine-grained editor since the editable granularity is at the chunk level. It does not support any form of real-time viewing of updates. PREP supports asynchronous collaboration over time. The versioning process of the drafts is a desirable feature of PREP.

PAGE 34

24 3.9 Flexible JAMM Flexible JAMM (Java Applets Made Multi-User) [19] is a replicated architecture collaboration-transparency system that incorporates the approach of dynamically replacing single-user objects with collaboration aware versions. It is developed at the Virginia Polytechnic Institute and State University by Begole et al. Flexible JAMMs replicated architecture is based on an earlier replicated collaboration-transparency system, called JAMM developed by Begole et al. at JavaSoft in 1996. Flexible JAMM uses an image-copy scheme provided by the Java Object Serialization (JOS) to send the current state of a shared object to newcomers. JOS provides the basic capability needed to migrate applets to new participants. Flexible JAMM was used to dynamically convert Notepad; a java based single user editor, to allow multiple users to collaborate on the document. The converted system allowed users to edit different parts of the file simultaneously. Flexible JAMM uses an operational transformation algorithm to enable concurrent editing without locking. In this algorithm, potentially conflicting operations may be aborted. Changes to the document are made through two atomic operations insert and remove. Each operation is called an edit. When an edit is performed at one site, the edit is broadcast to shared sites (ex: insert (4,abc). Each replica updates its copy of the document by transforming a remote to be consistent with its own set of local operations. This approach differs from the other in that remotely generated operations are not transformed directly. Instead, the local replica maintains a queue of previously applied operations (both local and remote) and their inverses. An operation is only kept in the queue until it is clear that all the sites have received and applied that operation.

PAGE 35

25 3.10 Multi-User Text Editor MUSE MUSE [20] was developed at the University of Kentucky in Tcl/Tk. It is a multi-user text editor that provides support for collaborating teams of users. A central server accepts connections from clients, each of which is a text editor. The server keeps track of which files are being used by more than one editor. Regions of files are locked while they are being edited. The granularity is one line. MUSE does not have any awareness distribution mechanism. MUSE depends on one point of central communication and there is no reliability mechanism in case of a crash. 3.11 DistEdit DistEdit [21] is a distributed toolkit for supporting multiple group editors for collaboration in real-time. It is developed at the University of Michigan by Knister M and Prakash A. Different front-ends can be incorporated into DistEdit to let users collaborate with heterogeneous editors. Only one user known as master can edit the file text. All other users called as observers can just read the text and updates. Once the master relinquishes his status, any one observer can become the master and edit the text. The DistEdit system is designed as a modular toolkit that can easily be applied to existing visual editors. DistEdit provides a set of primitives for communication between different editors. The text update calls are mapped to DistEdit primitives that are broadcast to other sites that re-convert the primitives to their own update primitives. Each editor at distributed sites keeps an updated copy of the text. DistEdit's replicated architecture provides high degree of fault tolerance. It treats crash at one site as an editor exit from session. Since every site keeps its own copy of the file and an editor, the performance at the local sites is good. However, the total

PAGE 36

26 replication puts a high demand on broadcasting. The main drawback of DistEdit is the inability to edit a file concurrently. Its strict floor passing mechanism makes the editable granularity equal to the whole file. The ability to collaborate using heterogeneous editors is the most desirable aspect of DistEdit system. 3.12 Collaborative Editor SASSE SASSE is a second prototype after SASE, which was an interactive synchronous writing tool. This version also supports asynchronous editing an annotation mechanism is provided that allows authors to exchange notes and comments. It uses a replicated architecture with the shared document residing on each collaborators workstation. It has a centralized communication server on Unix box that communicates with the clients using TCP/IP protocol. The clients are Macintosh workstations. 3.13 Shared Books Shared Books [22] is a commercial collaborative management tool for an office information system. It is developed as part of the Xerox Viewpoint document processing system. A Shared Book helps the users of an office information system create a multi-part publication and manage it throughout its life cycle. It supports collaboration both by allowing different parts of the publication to be modified by different workers simultaneously and by ensuring that workers use the current revision of each part. It protects publication information by providing lock and access control. The Shared Book communicates the current status of the publication to each worker through a WYSIWIS viewing paradigm. Shared Books suffers from the limitation of fixed Editable Granularity. While this may be useful in the publication environment of Xerox, where parts of a publication are

PAGE 37

27 clearly defined, this may become a deficit in co-authoring of documents. However this application amply demonstrates how a concurrent editor can be effectively used for commercial purposes. 3.14 ShrEdit ShrEdit [23] is a synchronous multi-user text editor developed at the University of Michigan. ShrEdit runs on a network of Apple Macintoshes and is developed as a tool to explore the support of design meetings. ShrEdit allows multiple users to edit a set of documents collaboratively. Each user can have a number of shared and private windows open at any time. Shared window presents a view on the shared documents, each user having an edit cursor within the shared window allowing them to edit the document concurrently. Private windows contain documents which only one user can see and edit. ShrEdit uses locking mechanism to avoid collisions between the edits of different users. Other users edit actions are displayed in all shared windows with a low latency. A control window associated with each edit window displays the names of all the participants in the session. Through this a user can track other users and see what they are editing. ShrEdit does not have a strong model of the collaborative editing process behind its design. All users have equal access to the shared document. Awareness support in ShrEdit is rudimentary. Users have very little information about other users actions in the shared workspace. ShrEdit is designed to be run on Macintoshes and cannot run on other platforms. That becomes a major drawback considering that other platforms are more popularly used.

PAGE 38

28 3.15 NetEdit NetEdit [20] is developed at the Virginia Polytechnic Institute and State University by Zafer et al. NetEdit is a collaborative editor that allows communication between collaborators with a chat facility. The editor provides awareness about who else is participating in the same session. All the files that the user can edit through NetEdit are shared at the server. These files are organized hierarchically in directories and subdirectories. When a person logs into the system, he is provided with this hierarchical view of the files. A session consists of one or more users editing a particular file. He can either join an existing session or create a new session. A replicated architecture is used with a copy of the document residing at all sites. NetEdit does not use locking for concurrency control. It also uses a distributed operational transformation algorithm similar to the JAMM system. NetEdit like most of the other systems we have seen suffers from the drawback of single point of failure at the server. There is no reliability mechanism in case of a crash at the server. 3.16 mpEdit mpEdit [24] is a collaborative editor developed at NCSA (National Center for Supercomputing Applications) using the Habanero collaborative framework. mpEdit uses a centralized approach with tightly coupled collaboration. There is a coarse-grained lock for the entire document and one has to acquire the lock to edit the file. Hence it allows only one participant to edit at one time. There is no provision for passing awareness information to other users.

PAGE 39

29 3.17 Mother of All Concurrent Editors Version 1.0 MACE [1, 25] Version 1.0 is a fine-grained concurrent text editor. It was developed at the University of Florida in 1991. MACE V 1.0 is a synchronous shared editor developed in C using Unix 4.3 BSD sockets for communication. MACE V 1.0 was developed as a stand-alone program as well as an application for DCS Version 1.0. MACE V 1.0 uses locking for concurrency control. The level of sharing is controlled by mutual consent, so that users may collaborate to the degree desired, including the option to view updates in real-time. The EG of MACE V 1.0 is effectively zero bytes and this is a desirable feature incorporated into MACE V 2.0. MACE V 1.0 has many useful features like character level locking, real-time and user controlled update frequency. MACE V 1.0 runs only on the X Window System and is not platform independent. Also there is no reliable recovery mechanism in this system. If the 'Editor Manager' crashes for any reason, the whole session is terminated. This hinders the performance of persistent editing of files. MACE V 1.0 was a prototypical implementation. There are two other editors InterText InterMedia (Brown University) and ITeach (University of Virginia), which were developed. InterText was developed to run only Apple Mac environment. ITeach has the drawback of only user allowed to edit the file at one point of time. 3.18 Conclusion Each of the editors discussed in Chapter 3 have their own positive and negative points. However, none of the systems fully qualify as a fine-grained, platform independent concurrent text editor for close collaboration.

PAGE 40

30 GROVE with its fully replicated architecture provides a degree of fault-tolerance and reliability desirable for a collaborative system. This fully replicated architecture, however, puts a strain on the network bandwidth as it increases the communication overhead. GROVE does not fully qualify as a text editor as it is an outline viewing editor only. The tickle locks feature provided by CES is useful when the users forget to release their locks. However the editable granularity of CES is predefined and is equivalent to one section of text. CES does not support real-time updates. Aspects uses a moderated concurrent text editor, where a moderator who has special access rights creates and controls the conference. Quilt provides annotation, messaging and notification facilities. Quilt uses a hypertext methodology to link the base and nodes in a Quilt document. Quilt grants access to the document through the notion of social roles. Quilt too like CES does not support real-time updates and the EG is equal to one paragraph or a node. IRIS is a collaborative multi-user multimedia editing environment. IRIS does not impose any access restrictions for concurrency control and follows optimistic concurrency by following the social protocols instead. PREP Editor aids in collaborative document preparation with communication, planning and organized annotation. It is not a fine-grained editor as the EG is at the chunk level. The versioning process of the drafts is a desirable feature of PREP. It is presently implemented only on MAC. DistEdit is a distributed toolkit for supporting multiple group editors for collaboration in real-time. The ability to support heterogeneous editors is the most desirable aspect of DistEdit. The main drawback of DistEdit is the inability to allow users to edit a file concurrently. Calliope provides novel features such as public and external

PAGE 41

31 annotation, color coded text to reveal which author wrote which sections of a text. Another interesting feature is a tele pointer which shows a small dot at the location where another users mouse points to. Flexible JAMM is the only platform independent concurrent editor we have seen so far. Flexible JAMM does not use any access control mechanism for concurrency control. It uses operations transformation algorithm for ensuring consistency. Though the consistency is ensured with edits, users may lose some of the changes they make to the text. Shared Books is one of the commercial collaborative editors we looked at. It has a fixed editable granularity. The structure of the editable document in Shared Books is decided before a session for concurrent editing can ensue. ShrEdit is a synchronous multi-user editor but it is developed only to be used on Macintoshes. NetEdit uses a chat facility to allow communication between collaborators. NetEdit uses a fully replicated architecture to store documents. NetEdit suffers from the inadequacy of fault tolerant computing. MACE version 1 has the desirable features of fine-grained concurrent editing, locking based concurrency control and an option for choosing real-time updates. However this editor can only be run on Unix X-Windows system and has no reliable recovery mechanism. There is a central editor manager which controls a session and a crash for any reason would leave the system in an inconsistent state. We have looked at most of the existing editors in Chapter 3. In Chapter 4 we discuss the requirements and design of MACE.

PAGE 42

CHAPTER 4 REQUIREMENTS AND DESIGN 4.1 Introduction In Chapter 4 we look at the requirements and design of MACE. MACE is the designed as the shared text editor of DCS and should also be capable of functioning as an independent collaborative text editor. MACE is designed with a minimum editable granularity with a friendly user-interface. The details of collaboration should not alter the way a user edits a file unless absolutely necessary. MACE ensures that the amount of network communication is kept to the minimal for efficient functioning of the system. One primary requirement of MACE is that it should be platform independent. MACE is designed as a modular concurrent editor with the ability to add in features with relative ease. MACE provides awareness information with respect to the actions of the other users editing the same file. MACE supports different modes of editing a file. The user can use MACE in read mode, edit mode or in a snapshot mode viewing a snapshot of another users screen. The EG of MACE has to be minimal and the UG should be kept to the minimum necessary to reduce network communication. MACE has a design feature to retrieve only the necessary updates from remote sites without clogging the network with unnecessary updates. The update frequency of a users updates can either be controlled by a user or can be periodic. After looking at the requirements and design we have a brief discussion on how MACE enhances the Distributed Conferencing System (DCS) in close collaboration. 32

PAGE 43

33 4.2 Requirements MACE is primarily designed to be the shared text editor of DCS. However it is also required that MACE is capable of functioning as a shared text editor independent of DCS. MACE is designed as a tool for close and synchronous collaboration requiring minimum editable granularity. The interface of MACE is required to be user-friendly with the users being aware of the shared editing and at the same time not unduly bothered by the details of collaboration. MACE uses a locking system to prevent collision between the edited areas of different users accessing the file. One of the primary requirements of a group editor is that it has to be usable by a single user. Authors working with a group editor want to have at least the facilities and the accessibility they have working with their single user editor. One of the factors satisfying this requirement is low response time of the editor. Most of the processing in MACE is performed at the user's workstation. The amount of network communication required for collaboration is kept to the minimum required. The design used to achieve collaboration with minimum communication between remote sites is discussed in detail in design features. MACE is designed to be fault-tolerant with the capability to handle unexpected events like system crashes. MACE utilizes the history versioning capability of DCS for maintaining versions of the file. This helps authors keep track of the changes to the document overtime. One other requirement of MACE is the provision for implicit sessions. Users need not explicitly start a session to edit a file, the session should be dynamic with users entering and leaving the session at their choice.

PAGE 44

34 MACE makes use of the Secure Communication Services (SCS) [26] of DCS for secure encrypted communication between different users editing a file. This enables MACE to be used for applications with high security requirements. Group work involves people working on different hardware and software platforms, collaborative applications should be designed to operate on different platforms. MACE is designed to be platform-independent as is the DCS system. MACE is designed in modules with clearly defined layers of interfaces between modules, making it easier to extend its capabilities beyond the present requirements to suit the changing needs of the users. The MACE user interface is clearly separated from the underlying collaboration processes. This user interface can be easily modified and customized to the needs of a group of users without affecting the structure of the system. The files editable by MACE are required to be saved in plain ASCII text format, making them accessible by the user's favorite editor when the file is not shared. The users should be able to get information on which user is accessing which sections of the document. Users should be able to access the updates of other users, while allowing for private edits by authors as an option. There should be different modes of editing/viewing a file in MACE to cater to the specific needs of the users using the system. These modes are discussed in detail in the design features section of Chapter 4. We have briefly seen the requirements of the shared concurrent editor developed. Now we discuss the design features of MACE in detail, which meet our requirements specified. 4.3 Design The MACE window appears as another resizable window on the user's screen, which can be minimized or maximized. The user is free to move between his private

PAGE 45

35 areas and his MACE window. The usernames of the people currently editing the file is accessible by the user. The user to edit the same or different files can invoke multiple MACE windows. The editor commands can be accessed by mouse click operations on command buttons and menu items. MACE has four modes of editing a file. The user can operate on a file in one of following four modes. The four modes are shared read mode, snapshot mode, shared edit mode and private edit mode. In addition to these a user can edit a file in the extra copy editing mode which is discussed shortly. In the shared 'Read' mode, the user can view the contents of the file without being able to edit the file. In this mode the user's screen is refreshed with the committed updates by other users periodically. All the users start in this mode initially. In the shared edit mode, the user will first acquire a lock over a part of the file specified by the start and end locations. Once the user acquires a lock, he will be able to edit that part of the file. The user has the option of making the edits private or shared. When the user makes his edit private, updates will not be sent to the remote sites. In shared mode the updates are automatically sent to the remote sites periodically. The user can lock only one section. However, if the user desires to edit more than one section, multiple MACE windows can be invoked on the same file. In the snapshot mode, the user can request to see the snapshot of the screen of another user. For this to be possible, the latter has to accept the request for snapshots. The snapshot will be shown in a pop up window and the user cannot edit in this window.

PAGE 46

36 Extra copy editing mode is used when the user wants to edit a section of the text already locked by another user. The user invokes extra copy of the file and starts editing the section of the file he wants to. The DCS voting mechanism Decision Support System (DSS) [29] will be used to decide on which edit to finalize. Essentially two copies of the file are created and the voting mechanism will help in resolving the copy to be used further. If a user wants to synchronize with an extra copy being edited, the user can invoke multiple MACE windows to keep track of all the different copies. The EG of MACE is equivalent to zero bytes. The user can request a lock between any two bytes of text in the file. If the user specifies the same byte as start and end location, the lock area will be zero bytes initially. The size of a locked area can be anything between zero bytes and the length of the file. In this case the CI can be infinity. However there are other limitations on the number of users who can concurrently edit a file. The prominent among the reasons is the network speed. We know that any network is only as fast as its slowest link. It applies to MACE also. If there is a user editing a file with a relatively slow network connection, the communication among all the edit windows slows down considerably. To provide a considerable speed in updates, the number of users editing that file should be minimal. Also some individual workstations can have a limited number of open network connections. The number of users will also be limited by this number. Theoretically any number of users will be able to edit a file concurrently. The UG of MACE is equivalent to one section of the text and that particular section can be of any size, depending on the user's locked area. Updates are always sent as a

PAGE 47

37 section of text. The locked section UG is the minimum granularity possible as the user can change the text anywhere in the locked section. The UF of MACE can be controlled by the user. MACE has a default periodic frequency. The user can disable the default and make the updates user controlled. MACE can potentially have a real-time frequency by making the frequency minimum. This will make difference between periodic update frequency and real-time update frequency insignificant. The updates in MACE are completely controlled by the user's site. The updates of remote sites are not automatically sent to the user's local MACE window. The updates are requested by the user's site periodically. The contents of update will depend on the portion of the screen the user is viewing at that time. The user site keeps track of which parts of the file are being viewed by the user. As each section of a MACE file is no more than a finite small size (further discussed in Chapter 5), the active section combined with two or three contiguous sections will not be more than a finite amount in size. Hence the set of active sections on a users screen is limited. These active sections are continuously changed as the user scrolls through the text. When the user requests updates from a remote site, only the updates to active sections are sought. This feature reduces the amount of data being transmitted between remote sites. Consider the case of a number of users editing a very large file. If the whole file is transmitted for every update, then there is high probability of increased network latency. MACE ensures that transfer of complete text of huge files across network is eliminated to a large extent.

PAGE 48

38 MACE provides user awareness information in two forms. A user can request to see a pointer to the location where another user is editing. This is called a tele-pointer. A user can also point his mouse over a locked area to see who is editing that section. This will help collaborators to communicate more effectively. Figure 3. Architecture of DCS

PAGE 49

39 4.4 Distributed Conferencing System MACE is the concurrent text editor of DCS. It makes use of many features of DCS. First the users in the MACE session are the users in the DCS conference. DCS provides the access control facilities [27]. The DCS file system is used for the pool of MACE editable files. The SCS [26] module of DCS is used for secure communication among its local and remote sites. MACE makes use of the DCS [28] voting mechanism. The DCS discussion window can be used for asynchronous communication between the users sharing a file. MACE provides a good application for session and artifact based collaboration for joint authoring of text documents. 4.5 Architecture The architecture of a collaboration aware application can take two forms. An existing single-user application can be modified and enhanced to make it collaboration aware. A number of systems used this process for the design of concurrent editors. This method suffers from severe limitations, as the developer is constrained with the existing system in many ways. Most editors are specific to one platform or the other. This is an issue in developing a platform independent editor. We have opted to design the MACE as an open system as it is easier and also can provide better base for later improvements and enhancements. The MACE uses process distribution among user's workstations minimizing the workload on any one site. This architecture helps in minimizing network overhead. 4.6 Conclusion MACE is designed as a platform independent concurrent editor with a minimum editable granularity. MACE is the collaborative editing application for DCS and also functions as an independent concurrent text editor.

PAGE 50

40 The MACE editor should have minimum response time possible. MACE is designed to ensure minimum communication over the network and is designed as a modular concurrent editor to provide for further enhancements when needed. Users need not explicitly start a session for concurrent editing, all the users editing a file will be put in the same session by the application. MACE is designed to handle unexpected system crashes and recover to the last committed state smoothly without user intervention. The application provides awareness information of other users actions in the session through the use of tele-pointers and tooltip text on parts of the file. MACE supports a number of editing modes for the user to chose. A user always starts a session in a shared read mode. A user can chose to enter the edit mode by acquiring a pair of locks. A user can also choose to view a snapshot of another users screen with the consent of the latter. The UG of MACE is equivalent to one section of the text which is the part of the file editable by the user. MACE retrieves only the remote updates which have a higher probability of being viewed by the user. The updates made to the file which are not on users screen are not retrieved, thus reducing the amount of data transferred from remote site. MACE provides awareness information by displaying users in the session along with tele-pointers of other users on request. We have discussed the requirements and design for MACE in Chapter 4. In Chapter 5 we look at the implementation details of MACE to achieve the described design objectives.

PAGE 51

CHAPTER 5 IMPLEMENTATION We have seen the requirements of MACE and its design features in the Chapter 4. In Chapter 5, the implementation details to meet the design features are discussed. 5.1 Introduction MACE uses Java and RMI for implementing the system. Swing is used to design the user interface of the editor. MACE is designed in four modules. The file manager acts as the interface between the MACE editor and the file system. The edit manager acts as the central coordinator for all the edit windows editing a particular file. There can only be one edit manager per file with a number of edit windows for simultaneous editing. The user interface module is the interface used for display and editing of a file. MACE uses locking based concurrency control for concurrently editing a file. A user has to acquire a pair of locks before he can start to make changes to the file. The edit manager controls access to the parts of the file by granting locks to each user after checking for conflicts. The files in MACE are located in a distributed manner. Users can have files located on their site or at remote sites. MACE has an inbuilt reliability and recovery mechanism in case the edit manager crashes. The MACE uses a hierarchical order to decide the site to start edit manager in the case of the original site crash. However, a crash at an edit window site is treated as the user leaving the session. MACE is connected to the DCS history versioning system to keep track of the versions. This provides reliability to the MACE file system. 41

PAGE 52

42 In the coming sections we look at the implementation features in detail. 5.2 Platform and Programming Language The platform for the implementation has been chosen on the criteria of availability, portability and ease of implementation. The DCS system is implemented in Java [29] using RMI and Swing. MACE is also implemented in Java with the interface designed in Java Swing. MACE uses RMI for communication between different sites. MACE uses the SCS [26] module of DCS for secure communication between its remote sites. 5.3 Modules The MACE implementation consists mainly of four packages: the File Manager (FM), the Edit Manager (EM), Edit Window (EW) and the User Interface (UI). The FM is the start up module to run when the MACE application is used. The EM and EW are related to a particular session of a particular file. The UI is the MACE user interface implemented in Swing. The design of MACE is based on MACE V 1.0 [1]. MACE V 2.0 is an enhancement of MACE V 1.0. The four modules are discussed in detail below. 5.3.1 File Manager The FM in MACE is the file services daemon. FM is the interface for DCS file system and is responsible for acquiring the file lists, both local and remote, available for editing in MACE. When a user selects a file to edit, FM searches its tables to verify if an EM for that file is active. If an EM is already active then a new EW is created at users site. Otherwise both an EM and an EW are created at the users site. This EM now becomes the central point of communication for all EWs created for editing the particular file. When the file is to be saved the EM communicates the contents of the file to FM. FM is designed to interact with file system and save the file system. The FM is also

PAGE 53

43 designed to retrieve different versions of a file from DCS history versioning system. This may be done when a user requests to view a previous version of the file. EM EW EW EW EW UI UI UI UI EM EW EW EW EW UI UI UI UI FM Figure 4. MACE architecture The FM runs as a background daemon. The FM is displayed to the user with another interface, an object of which is instantiated at the start of MACE application. The interface helps the user in selecting a file for edit. The figure below shows the interface for MACE File Manager. 5.3.2 Edit Manager Each file that is edited is associated with an EM. EM acts as the central agent of communication for all the EWs on a file. The EM ensures process synchronization and consistency through serialization. It handles two forms of serialization: spatial and temporal. Spatial serialization is performed with the use of locking mechanism. No two users are allowed to edit the same portion of the file, thus ensuring spatial separation between users transactions. Temporal serialization is performed by maintaining FCFS

PAGE 54

44 order of processing requests. The integrity of the file is maintained with the use of these forms of serialization. Figure 5. MACE file manager. As MACE is a distributed program, EM is not designed to permanently reside at any one pre-determined site. EM will run on the site from where the first user invoked the use of a file. The site hosting EM on a file can change for each session. When the user site holding EM leaves the session, a new user site still using the file, will start running the EM. The EM controls the session. As the EM is the central point of communication, it is designed to carry minimum load. EM is designed to carry what are called administrative

PAGE 55

45 responsibilities, like granting locks, granting entry to new users and maintaining the most recent copy of the file. EM is also responsible for sending notifications to all EW sites when an event occurs. The EM is not involved in actual text edit in anyway. The user performs the actual updates on a file at the EW. 5.3.3 Edit Window The EW runs at the users site. Each user editing a file will have one EW running on his machine. The user can invoke more than one EW if one is editing different parts of the file. As the EW runs on the local machine, it is designed to accept the maximum processing load of editing and maintaining updates on the file. It is responsible for communication between the users interface and EM of the file. It is responsible for sending and receiving updates on the file with the EM and processing lock requests. EW daemon receives event notifications from EM and takes appropriate action. The notifications include events; lock granted, lock release, new user and user exit. The UI and EW are tightly coupled. If the user has chosen private edit, the EW sends the update on the section being edited by the user to EM when the user chooses to commit. If the user is in auto-commit mode, the EW periodically sends the latest updates on the section to the EM. The EW keeps track of the text updates of the user, the active sections on user screen and the edit mode of the user. EW periodically retrieves the most recent version of text of sections active on users screen from the EM. To reduce the amount of data retrieved, EW retrieves only the sections that are being edited by some other user. Different sites have different network bandwidths. It is inappropriate to impose the same communication overhead on all sites irrespective of their network speeds. MACE

PAGE 56

46 provides a facility for user to specify the periods of time one wants to send an update and receive updates. EW retrieves these settings from user preferences and sets the update frequency accordingly. This will help in reduction of excessive communication for users with slow network speeds. In other instances users with very good broadband connections can set the update frequency to a negligible amount of time. This will allow them to have a virtual real-time connection to the other users. Figure 6. MACE edit window 5.3.4 User Interface The UI module is the face of MACE. The UI communicates only with the EW in the users site. The UI is designed to be user-friendly. The user can find which sections of

PAGE 57

47 the text are locked and by whom. The text of the file is displayed in three different colors to the user. Each color represents different access rights on that section of that text. One color represents sections of text locked by other users. A second color represents sections of text locked by this particular user, which is editable. The third color represents sections of text, which are not locked by any one. To request a lock the user specifies the start location by clicking his mouse over that location. Then he clicks the start of edit area button. The same is done to specify the end location. Once the lock is granted the locked area is displayed in a different color and user can start editing in that section. Periodically the EW refreshes the users screen with the latest updates received. When the user scrolls his mouse on the section of text locked by others, the information of the user locking that section is displayed as a tool tip. This enables the user to interactively find the user editing a particular section. The UI is designed to keep track of the active sections on the users screen. As the user scrolls through the file, the sections are updated to active or inactive, as may be the case. Whenever there is a change in the text of a section, the new text is displayed to the users screen without causing any hindrance to the work the user is doing. A user can, upon request see the pointer to the location where the other user is editing. This is done in two steps. First the user initiates a request for the tele-pointer from another user; the latter users screen displays the request. On approval a real-time connection is established between the two users. The first user can then see the changes to the mouse and key cursor movements of the second user when he wishes. If there has to be two way displays of tele-pointers, the second user follows the same process as first

PAGE 58

48 user and gets his approval for tele-pointers. All this communication is performed directly between the users sites without the involvement of EM. This reduces any communication that may have additionally gone through the EM. 5.4 Concurrency Control MACE uses locking as the means for collision control. The user has to acquire a lock before he can start editing a file. The serialization is maintained in two forms: temporal and spatial as discussed previously. Initially the user is in the read mode. The user has to select start and end locations of the area he wants to edit before he can request a lock. The EW verifies if any one else locked the area. If not, the request is sent to the EM. If the lock request is granted, the EM increments its version number and then notifies all the EWs of the new lock. All the EWs will lock their sections and increment their version numbers. After acquiring the lock, the user can edit the section he locked until he releases the lock by himself. The updates are sent to EM periodically unless the user selects private edit option. In that case, the updates are sent whenever the user commits the changes. Once the user releases his lock, the section is opened for lock requests from other users. To avoid race condition in lock requests and in all communications, the EM maintains a version number. All the EWs maintain a version number of their own. If the version numbers do not match in any communication, the specific request is denied. The EW has to synchronize itself again with EM. For every lock request the version number is incremented. The version numbers are changed in case of five events; on user entry, on user leaving, on new locks, lock releases and on initiating new EM. The occurrence of any of these events is broadcast without delay to all user sites. A user cannot make any

PAGE 59

49 successful communication during a broadcast as the version numbers between user site and EM do not match. The user will resend the communication after he receives the previous broadcast. 5.5 Replication and Recovery The EM maintains a list of users accessing the file. Whenever a new user enters the session, the details are added to the list. This list is fully replicated at all sites. This list is useful in case of a failure. Whenever user commits his changes to the file, the updates are sent to the EM. This makes sure that the EM always has the latest committed copy of the file. All the updates to the EM are sent to at least two other EWs, thus ensuring that three sites have the latest committed copy at any time. If an EW crashes at any time, the EM tracks the failure. If the EW does not respond with an acknowledgement for a notification more than once, then it is construed as an EW failure. Then the locks held by the user are released and the user is removed from the list. Handling failure of an EW is thus straightforward, but if an EM fails then we need to have an elaborate mechanism to handle the situation. All the EWs have the user list. This list is consistent across all sites as any changes to the list are propagated immediately. In the event of EM not responding to any communication from an EW, the EW after verifying that EM is inaccessible will initiate a process of instantiating a new EM. The first EW alive in the users list will be requested to declare itself as the new EM. This EW in turn invokes a new EM and notifies all other users in the user list of the change of EM. Each EW then sends an acknowledgement back accepting the new EM. Now the new EM will manage the session as the central agent. Before initiating process for new EM, the EW checks with all other EWs in touch

PAGE 60

50 to see if any EW has an active connection with EM. This ensures that unless the EM lost communication of all users, there will not be a new EM at another site. The above recovery mechanism is ineffective if the EM is still alive and a subset of EWs loses connection to EM but not between themselves. Now, after this process, there will effectively be two independent EMs at the same time without communication between each other. This can happen if a subnet has its network connection cut from the rest of the world in the middle of a session. The EWs in the subnet have a different EM than the rest of the world. In this event the EM having access to the site where the file resides will write the original copy of the file. In most common cases the above mechanism will be sufficient for maintaining a smooth and reliable recovery mechanism. This will ensure that users will not lose their saved changes in case of an unexpected EM crash. 5.6 Conclusion MACE is implemented in Java, RMI and Swing. The choice of the programming language is made in view of its platform independence and to make the collaboration easier with DCS, which is implemented using Java. MACE design is split into four modules. The FM is the file manager interface dealing with the file system of the native operating system or the DCS File System. A user starts his MACE system with the FM. The EM is the central coordinator for all the edits on a MACE file. Every file in MACE has one and only one EM running at any time. EW is the module which runs at each site editing a MACE file. Each user has his own edit window and all the edit windows coordinate with the EM. If a user has more than one file open for edit, then he will have that many number of edit windows running on his

PAGE 61

51 site. The user interface module controls the display area of the user site. This module communicates only with the EW of the particular file on the site. The files in MACE are distributed across sites. MACE has an inbuilt recovery mechanism in case of a crash at an EM site which is central to the session of editing a file. MACE uses locking mechanism for collision avoidance among different edits on a file. The EM controls access to the sections of a file by all the edit windows. This will ensure the consistency of the file and serializability of the transactions. Chapter 6 concludes this thesis with a discussion on future work and by highlighting the unresolved issues in this version of MACE.

PAGE 62

CHAPTER 6 CONCLUSION In the conclusion of this thesis we shall review what we have discussed and analyze MACE to look at some of the improvements possible for MACE. 6.1 Introduction MACE is a fine-grained lock based concurrent text editor. As group activities have come to dominate the modern workplace, the need for collaborative editing tools is more than ever. MACE version 1 was developed at the University of Florida in 1991. This version of MACE is an enhancement over MACE Version 1.0 with the system completely redeveloped. Any collaborative editing system is desired to have a low granularity and high concurrency index. A concurrency control mechanism should have mechanisms to ensure file consistency, transaction serializability and avoid collisions. MACE uses a locking based approach to implement its concurrency control mechanism. We have reviewed a number of synchronous and asynchronous collaborative editors in comparison with MACE. This has helped us define the desirable characteristics of the system being developed. MACE is designed as an open system to provide for later enhancements to the application. MACE implementation is completed in four modules. Each of the modules has clearly defined interfaces with the other modules. This makes it easier to modify or enhance the available code. 52

PAGE 63

53 The development of MACE required that the system can be run on any platform and the development is modular. MACE used Java and RMI for the implementation of the system. MACE has a fault tolerance mechanism to ensure that edits are not lost due to unexpected crashes and the session is not interrupted. We have looked at the features of MACE in brief. Now we look at some of the deficiencies of MACE in terms of conceptual and design issues. 6.2 Conceptual Issues Conceptual issues are issues in concurrent editing that have not been satisfactorily resolved in the development of MACE. 6.2.1 Commenting and Annotation A common requirement of concurrent text editors would be the feature supporting commenting and annotation. When a number of authors are making modifications to a document, a facility to keep track of changes and the reasons for those changes would be very helpful. Commenting would be helpful in authors recording the reasons for making specific changes to the document. Annotation would be useful for authors to provide hyper linked information. Commenting would require a separate storage structure for the document. The separate storage structure is required to distinguish between the comments and original text. This would require that documents be stored in a specialized format readable by MACE application. This would contradict with the other requirement that the documents be readable by heterogeneous editors.

PAGE 64

54 6.2.2 Access Rights Presently the only access rights provided by MACE are read, update and no access. A user can update and modify any part of the file if he has an update right. Similarly, a user can read any part of the file if he has a read access right. But real life co-authoring situations require more fine-grained access control. Authors may want to make their changes to the file permanent, so that other users will not be able to modify that part of the file further. Some users may want parts of the file to be confidential. While still other users may want to specify which users can read the changes they made and which users cannot. These access rights if implemented would throw up more issues to deal with. The primary issue being the decision process of who gets those access rights. There should be a fair process of relegating access rights. If there are users who undo the changes made by the other users, then shared editing will be conflict ridden. No user can ensure that their changes will remain permanent. Although this issue is not resolved to satisfaction, the history versioning system of MACE is helpful. 6.2.3 Usage Analysis A proper analysis of MACE calls for the gathering and analysis of statistics on the usage of the system. These statistics may help us in tailoring the system to suit the exact needs of the users. A proper analysis is required to make MACE even more useful for the users. 6.3 Design Issues Design Issues are the issues in implementation that have not been resolved satisfactorily in this version of MACE.

PAGE 65

55 6.3.1 Decision Support In the present version, the decision support for MACE is provided by the DCS. When MACE is used as a stand-alone editor it does not have a decision support system. That feature would be helpful for stand-alone editors as well. 6.3.2 Extra Copy Editing Extra copy editing in the present version of MACE is essentially a creation of two different copies of the file with the same name. The section in conflict should have two different copies. But, the sections of the file not in conflict should be common to both the files. MACE does not support this feature. 6.3.3 Replication Strategy The file in MACE is fully replicated in at most three sites. These three sites are right now chosen on the basis of the order of their entry into session. While the implementation of this method is easier and relatively efficient, there are some flaws with this implementation. If all the first three sites editing a file are located in one LAN, then a failure of the LAN network connection will render the whole session a failure. Similarly, if one of the first three sites has a very low network bandwidth, then the whole communication of the session is slowed down. There can be a better strategy of selecting the sites for replication of the file. This is yet to be implemented. 6.4 Future of MACE This implementation of MACE has been mainly designed with the ideas of the DCS team and some research done by other institutions before. There are very few research institutions that tried to gather data regarding usage and target groups of shared editors. We plan to put MACE into use and collect data regarding the patterns of its

PAGE 66

56 usage. The next step would be to provide enhancements for MACE that are tailored to the needs of the user with prior knowledge of the patterns of usage. There are a variety of applications for a shared editing tool. Each application requires customized features. Like joint software development would involve syntax checking tools in the editors and co-authoring documents would require support for annotation. A future work on MACE may involve customization of the application for different user communities. 6.5 Conclusion This thesis presented the design and implementation of MACE, the Mother of All Concurrent Editors version 2. This implementation is a step towards the realization of the goal of achieving a fine-grained, platform independent and user-friendly concurrent editor.

PAGE 67

LIST OF REFERENCES 1. Pelimuhandiram H., and Newman-Wolfe R. E., MACE: A Fine Grained Concurrent Editor, Conference Proceedings on Organizational Computing Systems, Atlanta, GA, November 991, pp. 240-254. 2. Olson J., Olson G., Storrosten M., and Carter M., How a Group-Editor Changes the Character of a Design Meeting as well as its Outcome, Proceedings of the 1992 ACM Conference on Computer-Supported Cooperative Work, Toronto, Canada, November 1992, pp. 91-98. 3. Stefik M., Bobrow D. G., Lanning S., Tartar D., and Foster G., WYSIWIS Revised: Early Experience with Multi-User Interfaces, Proceedings of the Conference on Computer Supported Cooperative Work, Austin, TX, April 1986, pp. 276-290. 4. Newman-Wolfe R. E., Ramirez C. L., Pelimuhandiram H., Montes M., Webb M., and Wilson D. L., A Brief Overview of the DCS Distributed Conferencing System, Proceedings of the Summer 1991 USENIX Conference, Nashville, TN, June 1991, pp. 437-452. 5. Neuwirth C. M., Kaufer, D. S., Chandhouk R., and Morris J. H, Issues in the Design of Computer Support for Co-Authoring and Commenting, Proceedings of the Conference on Computer-Supported Cooperative Work, Los Angeles, October 1990, pp. 183-195. 6. Edwards W. K., Policies and Roles in Collaborative Applications, Proceedings of the 1996 ACM Conference in Computer-Supported Cooperative Work, Boston, April 1996, pp. 11-20. 7. Oszu T. M., and Valduriez P., Principles of Distributed Database Systems, Prentice-Hall, Englewood Cliffs, NJ, 1999. 8. Coulouris G. F., and Dollimore J., Distributed Systems, Addison-Wesley Publishing Company, Avon, UK, 2001. 9. Sullivan T. P., A Dynamic Two Phase Locking Concurrency Control Protocol, University of Florida, Gainesville, Master's Thesis, 1989. 10. Lantz K. A., An Experiment in Integrated Multimedia Conferencing, Proceedings of the Conference on Computer Supported Cooperative Work, Austin, TX, April 1986, pp. 267-275. 57

PAGE 68

58 11. Ellis C. A., Gibbs S. J. and Rein G. L., Design and Use of a Group Editor, MCC Technical Report Number STP-263-88, 1989. 12. Greif I., and Sarin S., Data Sharing in Group Work, Proceedings of the Conference on Computer Supported Cooperative Work, Austin, TX, April 1986, pp. 175-183. 13. Greif I., Seligar R., and Weihl W., A Case Study of CES: A Distributed Collaborative Editing System Implemented in Argus, IEEE Transactions on Software Engineering, Volume 18, Number 9. September 1992, pp. 827-839. 14. Leland M. D. P., Fish R. S., and Kraut R. E., Collaborative Document Production Using Quilt, Proceedings of the Conference on Computer-Supported Cooperative Work, Portland, OR, ACM, September 1988, pp. 206-215. 15. Koch M., and Koch J., Using Component Technology for Group Editors The IRIS Group Editor Environment, Proceedings of Workshop on Object-Oriented Groupware Platforms, Lancaster, UK September 1997, pp. 44-49. 16. Koch M., Design Issues and Model for a Distributed Multi-User Editor, Institut fur Informatik, Technische Universitat Munchen, Germany, 1995, pp. 359-378. 17. Borghoff M. U., and Teege G., Applications of Collaborative Editing to Software Engineering Projects, Institut fur Informatik, Technische Universitat Munchen, Germany, 1993. 18. Whalen T.J., Design Issues for an Adaptive Mobile Group Editor, Masters Thesis, University of Waterloo, Waterloo, Ontario, Canada, 1997. 19. Begole J.M., Flexible Collaboration Transparency: Supporting Worker Independence in Replicated Application Sharing Systems, Ph. D. Dissertation, Virginia Polytechnic Institute and State University, Blacksburg, VA, 1998. 20. Zafar A., NetEdit: A Collaborative Editor, Masters Thesis, Virginia Polytechnic Institute and State University, Blacksburg, 2001. 21. Knister M., and Prakash A., DistEdit: A Distributed Toolkit for Supporting Multiple Group Editors, Proceedings of the Conference on Computer Supported Cooperative Work, Los Angeles, October 1990, pp. 343-355. 22. Lewis B., and Hodges J., Shared Books: Collaborative Publication Management for an Office Information System, Conference Sponsored by ACM SIGOIS and IEEECS TC-OA on Office Information Systems, Palo Alto, CA, March 1988, pp. 197-204. 23. Dourish P., and Bellotti V., Awareness and Coordination in Shared Workspaces, Proceedings of ACM Conference on Computer Supported Cooperative Work, Toronto, Canada, November 1992, pp 107-114.

PAGE 69

59 24. Chabert A., Grossman E., Jackson L. S., Pietrowiz S. R., and Seguin C., Java Object-Sharing in Habanero, Communications of the ACM, June 1998/Volume 41, Number 6, pp. 69 25. Pelimuhandiram H., MACE: The Mother of All Concurrent Editors, Masters Thesis, University of Florida, Gainesville, 1991. 26. Aringunram R., Secure Communication Services for Distributed Conferencing System, Masters Thesis, University of Florida, Gainesville, Fl, 2002. 27. Manian V., Access Control Model for Distributed Conferencing System, Masters Thesis, University of Florida, Gainesville, Fl, 2002. 28. Kakarparti A., Distributed Support Service for Distributed Conferencing System, Masters Thesis, University of Florida, Gainesville, Fl, 2002. 29. Naughton P., and Schildt H., The Complete ReferenceJava 2, Berkeley, CA, Tata McGraw-Hill, 2002.

PAGE 70

BIOGRAPHICAL SKETCH Vijaya Rangadham Komaragiri was born in the city of Hyderabad, Andhra Pradesh, India. He grew up in Vikarabad, Andhra Pradesh, India, and completed his elementary and high school in Vikarabad. He then went to Hyderabad to complete his Bachelor of Engineering in Computer Science and Engineering from Osmania University, Hyderabad. He completed his undergraduate degree in 2001 and went on to the University of Florida to pursue a Master of Science degree in computer engineering, which he completed in 2004. 60


Permanent Link: http://ufdc.ufl.edu/UFE0005340/00001

Material Information

Title: Mother of All Concurrent Editors Version 2.0
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0005340:00001

Permanent Link: http://ufdc.ufl.edu/UFE0005340/00001

Material Information

Title: Mother of All Concurrent Editors Version 2.0
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0005340:00001


This item has the following downloads:


Full Text












MOTHER OF


ALL CONCURRENT EDITORS
VERSION 2.0


VIJAYA RANGADHAM KOMARAGIRI

















A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2004

































Copyright 2004

by

Vijaya Rangadham Komaragiri

































This thesis is dedicated to my parents.















ACKNOWLEDGMENTS

I thank Dr. Richard Newman for his continued cooperation and encouragement

during the course of my thesis. I also thank Drs. Shigang Chen and Ye Xia for serving on

my committee, and for their valuable comments.

I would like to thank all the DCS group members (past and present) for their

support and ideas. I specially thank Harsha Pelimuhandiram and Vijay Manian, whose

previous work and input to the project helped me immensely.

I wish to express my thanks to my family.
















TABLE OF CONTENTS

page

ACKNOW LEDGM ENTS ........................................ iv

LIST OF FIGURES .............. ........................viii

ABSTRACT.................. .................. ix

CHAPTER

1 INTRODUCTION ................... .................. .............. .... ......... .......

1.1 Motivation............................. ... .... .......... 1
1.2 Conclusion ........................... ...........................3
1.3 Thesis ..................................3................................................

2 COLLABORATION AWARE SOFTWARE ............................................................4

2 .1 Introdu action ............... .. ................ ........................................... 4
2.2 Issues in Collaboration Aware Software......................................................4
2 .2 .1 P rom ptness ...................................... ............................................ 5
2.2.2 C collaboration D istance................................................5
2.2.3 Presenting and V iew ing ................................................................ ..........5
2.2.4 Seams ............................................... ........ 6
2.2.5 Social Roles of Collaboration ............ ...............................6
2.3 Concurrent Editing ........... ............ ........ .......... ....... .... .. ...............6
2.3.1 Concurrency Index and Editable Granularity .........................................7
2.3.2 Update Frequency ..............................................7
2.3.3 U pdate G ranularity............................. ................ 8
2.4 Design Issues .......................... .................. ......... 8
2.4.1 U ser Perspective............... .................. ...... ....... ..... ..............8
2.4.2 Distribution and Replication...........................................9
2.4.3 C oncurrency C ontrol................................. .................9
2.5 Issues in C oncurrency C ontrol.........................................................................9
2.5.1 Collisions .................................................... ........9
2.5.2 File Consistency ................ .. ...................................... .. .......... 10
2.5.3 Serializability ....................... .......... ........................ .............. 10
2.6 Methods of Concurrency Control ....................................10










2.7 Architecture............................................... ...................... 12
2.7.1 Centralized Architectures.................. ............................................ 12
2.7.2 Replicated Architectures.................. .................................................13
2.7.3 Hybrid Architectures................................ .......... 14
2.8 Conclusion...................................................15

3 OTHER SHARED EDITORS .................................................17

3.1 Introduction......................................................... .... ..... ........17
3.2 GRoup Outline Viewing Editor (GROVE)............... ...............17
3.3 Collaborative Editing System (CES) .........................................19
3 .4 A sp ects ...................................... ............................................ 2 0
3 .5 Q u ilt ......................... ........ ...............2 0
3.6 Multimedia Editing Environment IRIS......................................................22
3.7 Calliope......................................................... ...... ........ ........ 22
3.8 Editor PREP ....................................... ................23
3.9 Flexible JAM M ...................................... ............. ....... .. .....................24
3.10 M ulti-User Text Editor M USE ............................. ...............25
3.11 DistEdit ................. ............ ......... ..........25
3.12 Collaborative Editor SA SSE .................................. .................. 26
3.13 Shared Books .......................................... ...... ...............26
3.14 ShrEdit ................................................27
3.15 NetEdit................ ...............................28
3.16 mpEdit.......... ......... ........ ....... .. ................. 28
3.17 Mother of All Concurrent Editors Version 1.0 ................. .................. ......... 29
3.18 Conclusion ............................... ...................... ....................29

4 REQUIREMENTS AND DESIGN......................................................... 32

4.1 Introduction .................................. ..... ...............32
4.2 Requirements ........................ ....................... ..............33
4.3 Design................................................ ........ 34
4.4 Distributed Conferencing System ........ .......................................39
4.5 Architecture...................... ................. ..........39
4.6 Conclusion ................................................39

5 IMPLEMENTATION..................... ........... ......... 41

5.1 Introduction............... ...... .................... ...........41
5.2 Platform and Programming Language.................................................42
5.3 Modules........................................ .........42
5.3.1 File Manager ......... ......... ......... ....... ................ 42
5.3.2 Edit M manager. ........ .. ................. ... ..............................43
5.3.3 Edit Window ............ .... .................. .. ................. 45
5.3.4 User Interface...................... ........ ..... ................ 46
5.4 Concurrency Control.................................... ............... 48










5.5 R eplication and R recovery .......................................................................... ........49
5.6 Conclusion ....................................................50

6 CONCLUSION.................... ..........................52

6.1 Introduction...................................... ........................................52
6.2 Conceptual Issues................................ ...............53
6.2.1 Commenting and Annotation.............................. .... ........ 53
6.2.2 A access Rights................. .... .............................................. 54
6.2.3 Usage Analysis............ .................... 54
6.3 Design Issues .................................................54
6.3.1 Decision Support............................. ...............55
6.3.2 Extra C opy E diting ........................................ ................. 55
6.3.3 R eplication Strategy ...................................................................... 55
6.4 Future of M ACE .............. .................. .......... ......... ............ 55
6.5 Conclusion ....................................................56

L IST O F R E FE R E N C E S .............................................................................. 57

BIOGRAPHICAL SKETCH ............................................... 60
















LIST OF FIGURES

Figure page

1 Centralized architecture...........................................12

2 Fully replicated architecture........ ................................ 13

3 Architecture of DCS..................... ................. 38

4 M A CE architecture ............................. ............43

5 M A C E file m manager. .............................................................44

6 M A C E edit w window .............................................................46
















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

MOTHER OF ALL CONCURRENT EDITORS
VERSION 2.0

By

Vijaya Rangadham Komaragiri

August 2004

Chair: Richard E. Newman
Major Department: Computer Information Sciences and Engineering

The utility and popularity of collaborative applications has been growing in recent

years owing to geographically diverse workgroups. Collaborative concurrent text editors

are an extremely useful tool in collaborative group work. A number of concurrent text

editors have been developed in the past 2 decades. However none qualifies as a full-

fledged, synchronous, platform-independent concurrent text editor.

Mother of All Concurrent Text Editors Version 2.0 (MACE) is a platform-

independent object-oriented distributed program that supports fine-grained concurrent

text editing. MACE is a synchronous group editor that provides support for fault

tolerance with a reliable recovery mechanism to recover from crashes.

Distributed Conferencing System Version 2.0 (DCS) is being developed at the

University of Florida under the guidance of Dr. Richard Newman. DCS supports

collaborative work among users distributed over diverse geographic locations. MACE is

designed as the concurrent editing application of the DCS. MACE runs as a stand-alone









editor independent of DCS, and also as an application to DCS. MACE is implemented

using Java, RMI and the interface is designed in Swing.

MACE uses a locking-based concurrency control mechanism to avoid collisions

between collaborators editing the same document. MACE supports implicit sessions

where users editing a particular file are put into the same session automatically by the

system. The system is designed to minimize communication overhead between the

different user sites.














CHAPTER 1
INTRODUCTION

1.1 Motivation

The first computers were designed for single users to run single jobs at a time.

Traditional single-user systems have given way to more advanced systems with multiple

users running multiple jobs on a single machine. More advances in computer networking

have enabled interconnection of multiple computers giving us access to remote resources.

With these traditional systems, communication between users has taken place in

asynchronous fashion (through computer mail, etc.,) however the work done in bringing

users together as groups has not been sufficient.

Group activities have come to dominate the modem workplace. The group activity

may be product development, scientific research, document preparation, administration or

just entertainment. In fact, many of the most common multi-user programs available are

games. Some of the recent research in the field has concentrated on developing several

programs with the intention of bringing users to collaborate more closely. Among these,

conferencing systems and shared text editors rank as the most useful programs for

collaboration.

Collaborative editing of a document is a common task nowadays. Writing groups

are often distributed over many locations, because of the globalization of the

organizations. Since many writers already use computers for their jobs, providing

computer support for the collaborative writing process has been identified as an important

goal. A concurrent shared text editor would be a very helpful tool in instructing and









demonstrating documents across remote sites. Typical examples of joint production of

documents are the co-authoring of research papers, and joint development of software

programs among other things. A great many documents are explicitly co-authored, and

even when only one author's name appears on the final version, the production of a

document is usually a collaborative task. Collaboration can take many forms. For

example, different authors of a document can edit the same section at different times,

each completing a draft before the next one begins. Alternatively co-authors could edit

different sections of a document simultaneously.

In the process of co-authoring a document, usually there is an initial meeting in

which the outline of the document is planned, and the responsibilities are assigned to

individual co-authors [1]. Each co-author works in relative isolation to produce their

sections. These individual sections are then assembled into a single complete draft, which

is then passed for serial editing of the latest draft. To maintain the consistency of the

document, the draft can be edited by only one person at one time. A concurrent editor

helps to provide solutions to most of the problems encountered in the above process.

With a concurrent editor the authors need not necessarily work in isolation, even before

the sections are merged. Turn taking is eliminated and the effort in co-ordination in

editing the integrated draft in final stages is greatly reduced. A study conducted at the

University of Michigan [2] found that a concurrent editing tool helped the group keep

more focused on core issues, waste less time on less important topics, and capture what

was said as they went.

Issues in developing a concurrent shared editor are many and interesting. Designing

and implementing such a system to meet the requirements is a fair challenge. The fact









that few shared editors are readily available (despite their great utility) motivated me to

produce a good concurrent text editor.

MACE Version 1.0 [1] was developed at the University of Florida a decade ago.

My study created an enhanced version, with support for platform independence and

reliable recovery.

1.2 Conclusion

Group activities and collaborative work have come to increasingly dominate the

modern workplace. There is a growing need for a concurrent editor to support such

collaborative activities. A great many documents are co-authored, and the use of

concurrent editors can eliminate many problems encountered during the process.

MACE Version 1.0 was developed at the University of Florida in 1991. My

implementation of MACE Version 2.0 is an enhancement of the concept of MACE V 1.0.

MACE V 2.0 also supports platform independence and reliable recovery from failures, as

enhanced features over Version 1.0.

1.3 Thesis

My thesis presents the issues and work that were involved in producing Mother of

All Concurrent Editors Version 2.0 (MACE V 2.0). Henceforth, MACE V 2.0 is referred

to as MACE. In Chapter 2, the concept and issues of collaboration aware software are

briefly discussed. Then issues of concurrent editing are discussed in some detail. In

Chapter 3, a discussion on some of the existing shared editors is given in light of the

issues discussed in Chapter 2. Chapter 4 gives details of the requirements and design of

MACE. In Chapter 5 we look at implementation of the system. Chapter 6 has a critique of

the editor and future extensions to MACE.















CHAPTER 2
COLLABORATION AWARE SOFTWARE

2.1 Introduction

Software that supports multiple users in cooperative work is known as

collaboration aware software. Computer Supported Cooperative Work (CSCW) is the

discipline that deals with the use of computers to support groups of people as they

cooperate to achieve their goals.

In Chapter 2 we introduce some of the issues in collaboration aware software in

general and how these issues affect the design of a collaborative application. Then we

introduce some of the terms in concurrent editing to help us analyze the issues in

concurrent editing. Issues in concurrent editing and methods of concurrency control are

discussed further. Different methods of "distribution and replication" are discussed.

Chapter 2 concludes with a discussion of pros and cons of centralized and distributed

architectures for the implementation of a concurrent editor.

2.2 Issues in Collaboration Aware Software

Collaboration takes place in real time and over a period of time. For example, a

video-conferencing system places a high-demand on real-time collaboration, while co-

authoring a document requires persistent control over the document. Therefore,

collaboration aware software should be able to control the shared material and the

environment.

Shared material mainly takes two forms: data and ideas. The distinction is made on

the basis of persistence. However ideas may be converted into stored data tangible by









computers. Requirements of collaboration aware software are the ability to communicate

ideas over a distributed environment. The ability to store ideas in the form of data, and

the ability to provide controlled shared access to data. One basic requirement of all

collaboration aware software is the ability to handle multiple users.

Some of the issues in collaboration aware software are the promptness with which

the user sites are kept consistent, the collaboration distance between users, the ways of

presentation and viewing, and the social roles of collaboration. We discuss each of these

issues in detail below.

2.2.1 Promptness

One aim of collaboration aware software is to provide prompt real-time support for

communication. Promptness requires every user site to be consistent with the others in

the shortest time interval possible. Therefore, support for real-time updates is desired.

2.2.2 Collaboration Distance

Collaboration distance [1] is the distance by which two or more collaborators are

separated by hardware or software restrictions. In other words, it is the limitation on the

intimacy of collaboration permitted by the system. This distance is associated by the

issues of granularity with which control of sections of a file can be granted exclusively to

one user, by distancing others from using that section.

2.2.3 Presenting and Viewing

As the collaborators are physically removed from each other, there should be

mechanisms by which the ideas and data are presented at remote sites. The presentation

of data at remote site brings up issues in viewing paradigms. There are many paradigms

for viewing; the most important of them are What You See Is What I See (WYSIWIS) [3]

and What You See Is What I May See (WYSIWIMS) [4]. WYSIWIS supports interaction









where everyone sees the same view of the shared material. A major shortcoming of this

method is the lack of privacy to the collaborator as strict WYSISIS outlaws the presence

of a private workspace. The other paradigm WYSIWIMS, allows the users to have their

own private workspaces, at the same time the viewer is given the option of seeing only

what he desires irrespective of changes at remote sites.

2.2.4 Seams

The coexistence of private and shared workspaces creates two environments for the

user. A seam is an obstacle in switching from one environment to the other. In this, the

WYSIWIMS paradigm allows for relatively seamless transition between shared and

private workspaces. Reducing the impact of these 'seams' is important as it reduces

confusion in users and improves the productivity of the collaboration.

2.2.5 Social Roles of Collaboration

Defining the roles and rights of the users in a collaboration is an important task in

collaboration [5, 6]. To provide support for social roles becomes an important issue in the

development of a collaborative application. There can be many different roles in a

collaborative environment to relegate the control of the document in preparation.

2.3 Concurrent Editing

Traditional text editors are not collaboration aware. They cater to a single user

editing one file at a time. These editors are not provisioned for the possibility of multiple

invocations attempting to edit the same file. In a networked file system, some

applications lock the entire file for editing in order to open them. This will not allow any

other user to open the file for editing until the application releases its lock. Microsoft

word locks the file before opening it and any other user can invoke the use of that file

only in read-only mode. Some other applications allow multiple invocations of a file but









are not collaboration aware. For example if a file is opened through two invocations

using notepad, only the changes made by one editor would affect the final version, the

choice of the editor being the most recent commit done by it. In most of the traditional

editors, sharing of a file can be achieved by passing it from user to another for edit. When

more than one user shares a file simultaneously, handling concurrency becomes an issue

to preserve the integrity of the file.

We introduce few terms that help us analyze the issues related to concurrent

editing.

2.3.1 Concurrency Index and Editable Granularity

Concurrency Index (CI) [1] is the maximum number of users who may use a file

concurrently. Editable Granularity (EG) [1] is the smallest discrete size of text by which a

file can be shared. For a file size F, the relation F
into chunks of size X and distribute among the users, then the editable granularity is X

and the concurrency index is less than or equal to F/X. Maximum concurrency is attained

when the size of the chunk is 0, which is when each user may use zero or more characters

concurrently. However, there are other issues which determine the concurrency index

(see section 4.2).

2.3.2 Update Frequency

The Update Frequency (UF) is defined as the frequency with which changes are

reflected at a remote site. The changes can be reflected at a remote site either in real-time,

periodic intervals of time or on events controlled by the users. If a user makes a change

and the changes are reflected at the remote site immediately with some network latency,

the update is propagated in real-time. If the changes are reflected at a remote site at

remote intervals of time, then the update frequency is periodic. If the updates are sent to









the remote site only when the user explicitly requests or sends the update or if there is a

commit on an event initiated by other users then the UF is user-controlled. It may seem

that a good concurrent editor should have real-time UF, but there are instances when this

should not be the case. In many instances, the writer may wish to keep his changes

private until he has composed a coherent edition of the text.

2.3.3 Update Granularity

Update Granularity (UG) is the amount of text updated at the remote site with each

local update. UG can take a range of values from one character to the whole file, and this

value can be pre-determined or user-controlled.

2.4 Design Issues

Having looked at the terms we now look at some of the design issues of concurrent

editing, concurrency and User Perspective.

A good concurrent editor minimizes the EG to achieve a maximum CI. Minimizing

EG also reduces the collaboration distance. For example, a fine-grained editor with EG of

one word separates collaborators only by a word.

2.4.1 User Perspective

A good concurrent editor should have the features that provide the user with the

ease of use, accessibility and ability to filter remote information. Information on other

collaborators such as their identification and their roles or modes of participation, e.g.,

"editing", "viewing", "inactive" modes should be readily available. Users should be able

to filter their usage to others. One wishing to see the work of another should be allowed

to do so with the consent of the former. The user should not be hindered by the fact that

the file is being shared unless necessary. The user should be made aware of the

collaboration but should not be taxed by its existence.









2.4.2 Distribution and Replication

Collaborative software is generally distributed over a network of computers. The

shared file could be in one site, partitioned, partially or fully replicated. Partitioning

provides a section of the file to each site. One approach of replication is known as

master-slave strategy where the master copy is changed and the updates are propagated to

the slave copies. Another approach is the distributed update control strategy where no

specific copy is treated as the master. Here, control is provided such that any changes to a

copy are reflected consistently in all other copies.

2.4.3 Concurrency Control

Concurrency control is the mechanism that ensures the consistency of a text file in

a distributed shared edit environment. There are different methods and issues involved in

concurrency control.

2.5 Issues in Concurrency Control

Some of the basic requirements of any concurrency control mechanism are the

avoidance of collisions, maintaining file consistency and ensuring serializability. We look

at each of these issues in detail below.

2.5.1 Collisions

Control of a concurrent text editor is based on avoidance or resolution of collisions

that happen when two or more users try to edit the same portion of the file. Collisions can

be resolved by ordering the text that result from concurrent editing, in a coherent manner.

The text can be ordered on the basis of time, but this may result in losing the syntactic

and semantic validity of the text. Collision avoidance is a more plausible solution in

handling concurrent text editing and is generally followed. To avoid collisions, we need

to exclude the concurrent updates on the same section of the file.









2.5.2 File Consistency

When a distributed editing system has the property of consistency, all sites of the

system have identical copies of the text. The system can be temporarily inconsistent

during the execution of a transaction. Once the transaction terminates, the system should

return to a consistent state [7]. Distributed concurrency control algorithms must ensure

that the system is consistent in a concurrent multi-transaction environment.

2.5.3 Serializability

Serializability is the most widely accepted correctness criterion for concurrency

control algorithms [7]. If each transaction by itself keeps a distributed system consistent,

then the simplest way to achieve a consistent system over multiple transactions is to

execute them in a serial manner. This method severely minimizes the concurrency index

of the system and hence we need to find control mechanisms that serialize only the

transactions that collide.

2.6 Methods of Concurrency Control

There are three common methods used for concurrency control of shared files:

locking, timestamping and optimistic concurrency control [8]. Locking ensures exclusive

access to parts of the file to maintain consistency, while timestamping and optimistic

concurrency control allow concurrent access to the same part of a file and consistency is

ensured at the time of commit to exclude collisions.

Locking ensures the serialization of transactions that collide. In locking based

concurrency control systems, a file update transaction is enveloped by a lock acquisition

and a lock release. No updates by other users are allowed on the same section until the

lock is released. This method serializes the colliding transactions in a mutually exclusive

manner. The transactions that do not collide may concurrently execute on the same file.









Locking restricts access to a section of the text file to a single user. This guarantees

collision avoidance.

Unlike locking based algorithms, timestamping algorithms do not maintain

serializability by mutual exclusion. They select a priori serialization order and execute

transactions accordingly [7]. New transactions are checked for conflicts and the

transaction with the most recent timestamp is rejected. To maintain the order, each

transaction and the sections of the file are timestamped. For this to be possible, the text

file has to be identified by sections. This method imposes restrictions on the editable

granularity, as the complexity of timestamping operations increase as the size of

timestamped section decreases and number of sections increase.

Optimistic concurrency control is based on the assumption that the number of

collisions is low. Transactions proceed at remote sites with no regard to collisions. Once

the edit is performed, the changes are sent to the remote sites. The changes are committed

only if there are no collisions. A major disadvantage with this method is the chance of

losing changes. Hence, this method is not suitable for concurrent editing of text files.

Another method of concurrency control is to maintain a list of multiple versions.

Each update generates a new version leaving the earlier as a history version. This method

has binding problem [9]. Each operation has to be bound to a version to ensure multi-

version serialization.

We have seen that unlike other methods of concurrency control locking ensures that

changes made to the file are committed by guaranteeing collision avoidance. The user

may lose changes with the timestamping, optimistic concurrency control and multi-

versioning mechanisms. The above reason combined with the relative simplicity and









accuracy, with which a locking mechanism can be implemented, made us chose the

locking based concurrency control for MACE.

2.7 Architecture

Distributed systems can be broadly categorized on the basis of process distribution

or on the basis of data distribution. Architecture for distributed systems can be centralized

architecture or a replicated architecture. As the name implies centralized architectures

have a central process controlling access to resources and maintaining the consistency of

the file. In distributed architectures on the other hand, the process is distributed across a

number of sites. We look at each of these in detail below.

2.7.1 Centralized Architectures

Centralized architectures have a single instance of an application running on one

machine. This machine is like the server that manages the application and smaller clients

at each site to handle the I/O.


DISPLAY PROCESS DISPLAY PROCESS DISPLAY PROCESS


Figure 1. Centralized architecture









The input from all sites is sent to the server. The output is then broadcast by the

application to all the clients. Synchronization of the processes is not an issue with this

architecture. There are significant disadvantages of this kind of approach. Since all the

input and output is directed towards one machine it may become a bottleneck in the

network. These architectures may use up heavy bandwidth and may not be suitable for

Wide Area Networks (WANs), where the network bandwidth is usually unpredictable

and not always available.

2.7.2 Replicated Architectures

The fully replicated architecture runs an instance of the application at each client

site. The local input is processed at each site and the output is produced for the user. In

most cases the local changes are of no importance to the remote sites. Only the necessary

input is multicast to remote sites.


Figure 2. Fully replicated architecture









The problem of network saturation at one point is greatly reduced with this method.

A significant disadvantage of fully replicated architectures is their inability to run on

different hardware architectures. The main disadvantage of replicated architectures is the

process synchronization. This imposes a high amount of communication overhead on

each of the processes in the system.

2.7.3 Hybrid Architectures

Partially replicated architectures can help solve the synchronization problem. While

most of the application is replicated as clients at remote sites, a part is centralized as

server. By channeling the input through the centralized process, it is possible to solve

synchronization by reserving the input order. In the design of such a server, we have to be

careful not to inundate the central process with unnecessary time-consuming duties. It is

possible to customize the clients to be able to execute on different hardware or software

architectures. Another conceivable hybrid architecture is a local cluster of users sharing a

centralized server and the collection of clusters together use a replicated architecture [10].

2.7.4 Open Systems

An open system is a system whose processes are modularized and are loosely

bound. Hybrid architectures can be built as open systems. Each type of process should

consist of a set of layers, modules, or objects that could be replaced by others with little

or no resulting effect to the rest of the system. This concept makes it easy to customize

the system to user and hardware needs.

The goals of MACE design include reduction of the dependence on the network

speed. MACE uses hybrid architecture with distributed processes at each client site

synchronized by a central process.









2.8 Conclusion

Collaboration takes place in real-time as well as over a period of time.

Collaboration aware software should be able to control the shared material as well as the

environment. Promptness in responding to user requests and minimal collaboration

distance are desirable characteristics of collaboration aware software. Collaborative

software should provide effective ways for collaborators to present ideas to each other.

The impact of "seams" in switching between shared and private workspaces should be

reduced. Collaborative software should also devise ways to provide support to mimic the

social roles of the collaborators to the extent possible.

A good concurrent editor should ideally have a high concurrency index with a low

editable granularity. The update frequency and update granularity of a concurrent editing

system should be designed for optimal performance on the network. Concurrency control

ensures the consistency of a file being edited in a distributed environment. To ensure the

consistency, the concurrency control mechanism should have a way to avoid collisions

between the actions of different users and the transactions of individual should be

serializable. A locking based concurrency control mechanism ensures that changes made

by user are not rolled back as there cannot be any collisions between users.

Timestamping and optimistic concurrency mechanisms ensure consistency by rolling

back colliding transactions and this may cause users to lose their edits at the time of

commit.

Centralized architectures have a single instance of application running on one

machine. This instance processes the inputs from all sites and broadcasts the output.

While this may be advantageous for synchronizing all the processes, it uses heavy

network bandwidth in excessive communication. A fully replicated architecture reduces






16


the amount of network communication but imposes a high amount of communication

overhead on each of the individual processes to synchronize. Hybrid architecture can help

solve the synchronization problem at the same time distributing the process load across

clients.

Chapter 3 discusses a few of the existing shared text editors in light of the above

issues and evolves a set of desired features for the implementation of MACE.















CHAPTER 3
OTHER SHARED EDITORS

In Chapter 3 we look at some of the existing collaborative editors and analyze each

of them. We look at the advantages and disadvantages of some of the popular group

editors.

3.1 Introduction

A brief discussion of the features and architecture of these editors helps us to define

our requirements in Chapter 4. We look at some of the synchronous editors like GROVE,

ShrEdit, CES, SASSE, Shared Books, Flexible JAMM, MUSE and Calliope. We also

look at some of the asynchronous systems such as PREP, DistEdit and Quilt.

In the following sections each of the editors is individually discussed and desirable

features are identified.

3.2 GRoup Outline Viewing Editor (GROVE)

GROVE [11] is an outline editor that supports real-time concurrent editing.

GROVE supports fine-grained access control and allows private items within the context

of public information. GROVE was developed at the Microelectronics and Computer

Technology Corporation, Austin.

A GROVE outline is a recursive structure consisting of structured items. Each item

has its own text and can contain sub-items of its own. Each item can be private, public or

shared. A user makes an item shared by choosing users who form a sub-group that will be

given access rights. Each user displays a view of the outline in a viewport. A view is a

subset of the outline to which the user has access and a viewer is a window that displays









an outline view. This distinction allows users to share views without sharing the viewers

displaying them. Users having write access can do the editing of a shared or public item

concurrently. Each user has his non-replicated cursor and is able to edit freely. Updates

appear in real-time on views that contain the item. GROVE employs a replicated

architecture. Concurrency control within items is achieved through the dOPT algorithm

that ensures consistency through out the shared views. dOPT is a totally distributed

algorithm that requires no locking of items.

The main limitation of GROVE is that each item is constrained to a single line of

text. Sharing in GROVE is done at two levels. The outline is first shared item by item

through the concept of views. If a user needs privacy to make the changes, he needs to

make the item private before editing, which will result in denying read access to others

while the item is being edited. The sequence of actions: making an item private, editing

and releasing it to public view, is equivalent to locking and releasing. Grove allows

multiple users to change an item simultaneously and ensures that they see these changes

in the same logical order. It does not use centralization or aborts to ensure global order,

optimistically expecting few inconsistent concurrent operations. The viewing paradigm of

similar shared views is a relaxed version of WYSIWIS as each user has his own cursor

and scroll bar. Update frequency of shared views is real-time and this is a desirable

feature in specific circumstances. GROVE is an outline editor and not a concurrent

editor.

The replicated architecture of GROVE ensures a high-degree of fault tolerance. The

dOPT algorithm does not require connection-oriented communication. Therefore

GROVE can be implemented over a network supporting datagrams. The totally replicated









architecture relies on broadcasting each change to all the sites putting a high demand on

network bandwidth.

3.3 Collaborative Editing System (CES)

CES [12, 13] is another group outlining system that supports fine-grained locks,

delayed transmission of changes to other users and distributed versions of the document.

CES was developed at MIT Cambridge.

CES supports collaborative editing of a structured outline whose leaf level nodes

are variable length text segments. Each text node in the document is owned by a

particular user, who is considered the primary author of the node and resides on the

machine of the owner. Secondary copies of the node are cached on other authors' nodes

and are kept consistent with the primary copy. Changes made by a user are transmitted to

other users only when they are committed. To reduce user overhead, CES supports

implicit commit. This option for the user is a useful feature.

CES supports 'tickle locks' to ensure that two users do not write to the same node

simultaneously. A user locks a node when he first edits it and retains the lock as long as

some editing activity occurs. Some other user can take the lock away from the holder if

the latter is idle for a certain amount of time. At this point, all changes made by the

holder are automatically committed. While this is convenient and useful in case one

forgets to release the lock, there may be times when the writer is in the middle trying to

compose his edit. Taking the lock away from him limits the ability of the writer by not

letting him to compose his edit into a coherent form. Since the file is statically partitioned

in CES, the editable granularity of CES is equal to the size of a section. CES does not

support real-time updates, its update frequency is periodic.









3.4 Aspects

Aspects is a commercial multi-user editing application, which provides multiple

modes of editing and a special user interface for explicitly requesting and releasing locks.

In Aspects, a special user called moderator creates a conference. Moderator has special

access rights.

Aspects supports three modes of concurrency control and the moderator determines

the one used dynamically. In the 'free for all' mediation mode, locking is at the paragraph

level. A user editing a paragraph sees a black bar on the side of it and other users see a

grey bar. In the 'medium mediation' mode, access to the complete document is serialized

and users use a pen passing mechanism to pass control. A user can be writing, waiting for

a pen, or just observing. Pen icons are used to pass control. A user can click on his closed

pen icon to request the pen. The user's icon starts blinking and turns into a raised hand

and the writer's open icon also starts blinking. The writer can click on the 'pen in hand'

icon to pass control to the first person waiting. Clicking on a black arrow shows the pen

status of the different participants. In the 'full mediation' mode, access to the document is

again serialized, but this time the moderator determines who gets the pen next after it has

been relinquished.

In Aspects, up to 16 people can be present in a conference simultaneously. When

the moderator closes the conference, everyone is sent a message informing about the

termination.

3.5 Quilt

Quilt [14] is a tool for collaborative document production. Quilt is developed at the

Bell Labs by Fish and Leland.









Quilt provides annotation, messaging, computer conferencing and notification

facilities to support communication and information sharing among the collaborators on a

document. Views of a document tailored to individual collaborators or to other of the

document's users are provided by Quilt. These views are based on the user's position in

the permission hierarchy that represents an extensible set of social roles and

communication types.

Documents in Quilt consist of a base and nodes linked to it using a hypertext

methodology. The nodes are of three types: the base document, which is publicly visible,

suggested revisions that may be swapped with paragraphs of the base and text and voice

comments. Quilt grants access to the document through a notion of social roles. Users

with proper rights may modify the document. Annotations may be attached to the

document for commenting the text. Quilt also keeps an activity log that is generated by

the system, which helps authors keep track of activities.

The text in Quilt is stored independent of any editor format. Therefore standard text

editors and other tools can be used in text manipulation. Quilt uses Orion as the

underlying system for object storage.

Quilt's annotation and messaging system makes it a powerful tool for collaborative

co-authoring over a period of time. Annotations help the authors know what the others

have done and to scrutinize and comment the document while proof reading another's

work. The interaction through Quilt is asynchronous. It does not support real-time

updates or communication. The update frequency is writer controlled. The editable

granularity is equal to a node or a paragraph of the base node.









The ability to use any editor is a favorable aspect of Quilt. The Quilt-Orion server

is the central point of coordination. Therefore, the system is prone to single point of

failure. The modular design of Quilt's architecture should facilitate its enhancement by

replacing existing modules with more powerful ones.

3.6 Multimedia Editing Environment IRIS

IRIS [15, 16, 17] is a collaborative multi-user multimedia-editing environment. A

document in IRIS is a collection of objects (text, graphics, video, bibliographic

references, etc.,) with relations between them. The relationships can be seen as a structure

on the objects. IRIS supports hierarchical structure trees.

The manner in which an IRIS document can be partitioned into content objects is

not regulated. The only restriction is that data of different media types have to be stored

in different objects. The 'storage layer' of IRIS provides document access and has

common interface for applications and is extensible for new content media types.

IRIS does not impose any access restrictions for concurrency control but follows

optimistic concurrency by following the social protocols instead. Any user can edit any

part of the document displayed.

3.7 Calliope

Calliope [18] is a shared editor developed at the University of Toronto, Canada.

Calliope has six major features that facilitate collaboration: access control, public

annotations, private text, external annotations, and unstructured text space and awareness

tools.

Calliope uses multi-level locking to maintain access control. Calliope allows users

to privately edit their text before making the changes public. Calliope provides awareness

tools to support awareness of other users' actions. Color-coded text reveals which author









wrote which sections of a document while a tele-pointer shows the location of a user's

mouse. There is a shared scroll bar which allows a person to follow another user's view.

Calliope uses an unstructured text space away from the main document to allow the

users to experiment while writing. For this purpose, Calliope provides a shared

scratchpad.

Calliope is written in Tcl/Tk, and its main text window is a Tk text widget.

3.8 Editor PREP

The PREP editor [5] aids in collaborative document preparation with

communication, planning and organized annotation. PREP was developed at the Carnegie

Mellon University.

The system defines chunks that may contain text, ideas or trees that are linked as in

hypermedia systems. Chunks are shared among collaborators. PREP allows authors to

define 'drafts' that they may intend others to access. The visual interface uses visual cues

such as different font sizes and spatial relationships to show the interconnections among

chunks. In co-authoring, one author edits a draft and gives a copy to another for

reviewing it while the first author incorporates new changes. The PREP editor aids this

process by allowing revisions to exist as distinct versions of the draft. It is presently

implemented only on MAC.

PREP is not a fine-grained editor since the editable granularity is at the chunk level.

It does not support any form of real-time viewing of updates. PREP supports

asynchronous collaboration over time. The versioning process of the drafts is a desirable

feature of PREP.









3.9 Flexible JAMM

Flexible JAMM (Java Applets Made Multi-User) [19] is a replicated architecture

collaboration-transparency system that incorporates the approach of dynamically

replacing single-user objects with collaboration aware versions. It is developed at the

Virginia Polytechnic Institute and State University by Begole et al. Flexible JAMM's

replicated architecture is based on an earlier replicated collaboration-transparency

system, called JAMM developed by Begole et al. at JavaSoft in 1996.

Flexible JAMM uses an image-copy scheme provided by the Java Object

Serialization (JOS) to send the current state of a shared object to newcomers. JOS

provides the basic capability needed to migrate applets to new participants.

Flexible JAMM was used to dynamically convert Notepad; a java based single user

editor, to allow multiple users to collaborate on the document. The converted system

allowed users to edit different parts of the file simultaneously. Flexible JAMM uses an

operational transformation algorithm to enable concurrent editing without locking. In this

algorithm, potentially conflicting operations may be aborted. Changes to the document

are made through two atomic operations insert and remove. Each operation is called an

edit. When an edit is performed at one site, the edit is broadcast to shared sites (ex: insert

(4,'abc'). Each replica updates its copy of the document by transforming a remote to be

consistent with its own set of local operations.

This approach differs from the other in that remotely generated operations are not

transformed directly. Instead, the local replica maintains a queue of previously applied

operations (both local and remote) and their inverses. An operation is only kept in the

queue until it is clear that all the sites have received and applied that operation.









3.10 Multi-User Text Editor MUSE

MUSE [20] was developed at the University of Kentucky in Tcl/Tk. It is a multi-

user text editor that provides support for collaborating teams of users. A central server

accepts connections from clients, each of which is a text editor.

The server keeps track of which files are being used by more than one editor.

Regions of files are locked while they are being edited. The granularity is one line.

MUSE does not have any awareness distribution mechanism. MUSE depends on one

point of central communication and there is no reliability mechanism in case of a crash.

3.11 DistEdit

DistEdit [21] is a distributed toolkit for supporting multiple group editors for

collaboration in real-time. It is developed at the University of Michigan by Knister M and

Prakash A.

Different front-ends can be incorporated into DistEdit to let users collaborate with

heterogeneous editors. Only one user known as master can edit the file text. All other

users called as observers can just read the text and updates. Once the master relinquishes

his status, any one observer can become the master and edit the text. The DistEdit system

is designed as a modular toolkit that can easily be applied to existing visual editors.

DistEdit provides a set of primitives for communication between different editors. The

text update calls are mapped to DistEdit primitives that are broadcast to other sites that

re-convert the primitives to their own update primitives. Each editor at distributed sites

keeps an updated copy of the text.

DistEdit's replicated architecture provides high degree of fault tolerance. It treats

crash at one site as an editor exit from session. Since every site keeps its own copy of the

file and an editor, the performance at the local sites is good. However, the total









replication puts a high demand on broadcasting. The main drawback of DistEdit is the

inability to edit a file concurrently. Its strict floor passing mechanism makes the editable

granularity equal to the whole file. The ability to collaborate using heterogeneous editors

is the most desirable aspect of DistEdit system.

3.12 Collaborative Editor SASSE

SASSE is a second prototype after SASE, which was an interactive synchronous

writing tool. This version also supports asynchronous editing an annotation mechanism

is provided that allows authors to exchange notes and comments. It uses a replicated

architecture with the shared document residing on each collaborator's workstation. It has

a centralized communication server on Unix box that communicates with the clients

using TCP/IP protocol. The clients are Macintosh workstations.

3.13 Shared Books

Shared Books [22] is a commercial collaborative management tool for an office

information system. It is developed as part of the Xerox Viewpoint document processing

system.

A Shared Book helps the users of an office information system create a multi-part

publication and manage it throughout its life cycle. It supports collaboration both by

allowing different parts of the publication to be modified by different workers

simultaneously and by ensuring that workers use the current revision of each part. It

protects publication information by providing lock and access control. The Shared Book

communicates the current status of the publication to each worker through a WYSIWIS

viewing paradigm.

Shared Books suffers from the limitation of fixed Editable Granularity. While this

may be useful in the publication environment of Xerox, where parts of a publication are









clearly defined, this may become a deficit in co-authoring of documents. However this

application amply demonstrates how a concurrent editor can be effectively used for

commercial purposes.

3.14 ShrEdit

ShrEdit [23] is a synchronous multi-user text editor developed at the University of

Michigan. ShrEdit runs on a network of Apple Macintoshes and is developed as a tool to

explore the support of design meetings.

ShrEdit allows multiple users to edit a set of documents collaboratively. Each user

can have a number of shared and private windows open at any time. Shared window

presents a view on the shared documents, each user having an edit cursor within the

shared window allowing them to edit the document concurrently. Private windows

contain documents which only one user can see and edit. ShrEdit uses locking

mechanism to avoid collisions between the edits of different users. Other users edit

actions are displayed in all shared windows with a low latency.

A control window associated with each edit window displays the names of all the

participants in the session. Through this a user can track other users and see what they are

editing. ShrEdit does not have a strong model of the collaborative editing process behind

its design. All users have equal access to the shared document.

Awareness support in ShrEdit is rudimentary. Users have very little information

about other users' actions in the shared workspace. ShrEdit is designed to be run on

Macintoshes and cannot run on other platforms. That becomes a major drawback

considering that other platforms are more popularly used.









3.15 NetEdit

NetEdit [20] is developed at the Virginia Polytechnic Institute and State University

by Zafer et al. NetEdit is a collaborative editor that allows communication between

collaborators with a chat facility. The editor provides awareness about who else is

participating in the same session.

All the files that the user can edit through NetEdit are shared at the server. These

files are organized hierarchically in directories and subdirectories. When a person logs

into the system, he is provided with this hierarchical view of the files. A session consists

of one or more users editing a particular file. He can either join an existing session or

create a new session.

A replicated architecture is used with a copy of the document residing at all sites.

NetEdit does not use locking for concurrency control. It also uses a distributed

operational transformation algorithm similar to the JAMM system.

NetEdit like most of the other systems we have seen suffers from the drawback of

single point of failure at the server. There is no reliability mechanism in case of a crash at

the server.

3.16 mpEdit

mpEdit [24] is a collaborative editor developed at NCSA (National Center for

Supercomputing Applications) using the Habanero collaborative framework. mpEdit uses

a centralized approach with tightly coupled collaboration.

There is a coarse-grained lock for the entire document and one has to acquire the

lock to edit the file. Hence it allows only one participant to edit at one time. There is no

provision for passing awareness information to other users.









3.17 Mother of All Concurrent Editors Version 1.0

MACE [1, 25] Version 1.0 is a fine-grained concurrent text editor. It was

developed at the University of Florida in 1991. MACE V 1.0 is a synchronous shared

editor developed in C using Unix 4.3 BSD sockets for communication.

MACE V 1.0 was developed as a stand-alone program as well as an application for

DCS Version 1.0. MACE V 1.0 uses locking for concurrency control. The level of

sharing is controlled by mutual consent, so that users may collaborate to the degree

desired, including the option to view updates in real-time. The EG of MACE V 1.0 is

effectively zero bytes and this is a desirable feature incorporated into MACE V 2.0.

MACE V 1.0 has many useful features like character level locking, real-time and

user controlled update frequency. MACE V 1.0 runs only on the X Window System and

is not platform independent. Also there is no reliable recovery mechanism in this system.

If the 'Editor Manager' crashes for any reason, the whole session is terminated. This

hinders the performance of persistent editing of files. MACE V 1.0 was a prototypical

implementation.

There are two other editors InterText InterMedia (Brown University) and ITeach

(University of Virginia), which were developed. InterText was developed to run only

Apple Mac environment. ITeach has the drawback of only user allowed to edit the file at

one point of time.

3.18 Conclusion

Each of the editors discussed in Chapter 3 have their own positive and negative

points. However, none of the systems fully qualify as a fine-grained, platform

independent concurrent text editor for close collaboration.









GROVE with its fully replicated architecture provides a degree of fault-tolerance

and reliability desirable for a collaborative system. This fully replicated architecture,

however, puts a strain on the network bandwidth as it increases the communication

overhead. GROVE does not fully qualify as a text editor as it is an outline viewing editor

only. The 'tickle locks' feature provided by CES is useful when the users forget to release

their locks. However the editable granularity of CES is predefined and is equivalent to

one section of text. CES does not support real-time updates. Aspects uses a moderated

concurrent text editor, where a moderator who has special access rights creates and

controls the conference.

Quilt provides annotation, messaging and notification facilities. Quilt uses a

hypertext methodology to link the base and nodes in a Quilt document. Quilt grants

access to the document through the notion of social roles. Quilt too like CES does not

support real-time updates and the EG is equal to one paragraph or a node. IRIS is a

collaborative multi-user multimedia editing environment. IRIS does not impose any

access restrictions for concurrency control and follows optimistic concurrency by

following the social protocols instead. PREP Editor aids in collaborative document

preparation with communication, planning and organized annotation. It is not a fine-

grained editor as the EG is at the chunk level. The versioning process of the drafts is a

desirable feature of PREP. It is presently implemented only on MAC.

DistEdit is a distributed toolkit for supporting multiple group editors for

collaboration in real-time. The ability to support heterogeneous editors is the most

desirable aspect of DistEdit. The main drawback of DistEdit is the inability to allow users

to edit a file concurrently. Calliope provides novel features such as public and external









annotation, color coded text to reveal which author wrote which sections of a text.

Another interesting feature is a tele pointer which shows a small dot at the location where

another user's mouse points to. Flexible JAMM is the only platform independent

concurrent editor we have seen so far. Flexible JAMM does not use any access control

mechanism for concurrency control. It uses operations transformation algorithm for

ensuring consistency. Though the consistency is ensured with edits, users may lose some

of the changes they make to the text.

Shared Books is one of the commercial collaborative editors we looked at. It has a

fixed editable granularity. The structure of the editable document in Shared Books is

decided before a session for concurrent editing can ensue. ShrEdit is a synchronous

multi-user editor but it is developed only to be used on Macintoshes.

NetEdit uses a chat facility to allow communication between collaborators. NetEdit

uses a fully replicated architecture to store documents. NetEdit suffers from the

inadequacy of fault tolerant computing. MACE version 1 has the desirable features of

fine-grained concurrent editing, locking based concurrency control and an option for

choosing real-time updates. However this editor can only be run on Unix X-Windows

system and has no reliable recovery mechanism. There is a central editor manager which

controls a session and a crash for any reason would leave the system in an inconsistent

state.

We have looked at most of the existing editors in Chapter 3. In Chapter 4 we

discuss the requirements and design of MACE.














CHAPTER 4
REQUIREMENTS AND DESIGN

4.1 Introduction

In Chapter 4 we look at the requirements and design of MACE. MACE is the

designed as the shared text editor of DCS and should also be capable of functioning as an

independent collaborative text editor. MACE is designed with a minimum editable

granularity with a friendly user-interface. The details of collaboration should not alter the

way a user edits a file unless absolutely necessary.

MACE ensures that the amount of network communication is kept to the minimal

for efficient functioning of the system. One primary requirement of MACE is that it

should be platform independent. MACE is designed as a modular concurrent editor with

the ability to add in features with relative ease. MACE provides awareness information

with respect to the actions of the other users editing the same file.

MACE supports different modes of editing a file. The user can use MACE in read

mode, edit mode or in a snapshot mode viewing a snapshot of another user's screen. The

EG of MACE has to be minimal and the UG should be kept to the minimum necessary to

reduce network communication. MACE has a design feature to retrieve only the

necessary updates from remote sites without clogging the network with unnecessary

updates. The update frequency of a user's updates can either be controlled by a user or

can be periodic.

After looking at the requirements and design we have a brief discussion on how

MACE enhances the Distributed Conferencing System (DCS) in close collaboration.









4.2 Requirements

MACE is primarily designed to be the shared text editor of DCS. However it is also

required that MACE is capable of functioning as a shared text editor independent of

DCS.

MACE is designed as a tool for close and synchronous collaboration requiring

minimum editable granularity. The interface of MACE is required to be user-friendly

with the users being aware of the shared editing and at the same time not unduly bothered

by the details of collaboration. MACE uses a locking system to prevent collision between

the edited areas of different users accessing the file.

One of the primary requirements of a group editor is that it has to be usable by a

single user. Authors working with a group editor want to have at least the facilities and

the accessibility they have working with their single user editor. One of the factors

satisfying this requirement is low response time of the editor. Most of the processing in

MACE is performed at the user's workstation. The amount of network communication

required for collaboration is kept to the minimum required. The design used to achieve

collaboration with minimum communication between remote sites is discussed in detail

in design features.

MACE is designed to be fault-tolerant with the capability to handle unexpected

events like system crashes. MACE utilizes the history versioning capability of DCS for

maintaining versions of the file. This helps authors keep track of the changes to the

document overtime. One other requirement of MACE is the provision for implicit

sessions. Users need not explicitly start a session to edit a file, the session should be

dynamic with users entering and leaving the session at their choice.









MACE makes use of the Secure Communication Services (SCS) [26] of DCS for

secure encrypted communication between different users editing a file. This enables

MACE to be used for applications with high security requirements.

Group work involves people working on different hardware and software

platforms, collaborative applications should be designed to operate on different

platforms. MACE is designed to be platform-independent as is the DCS system.

MACE is designed in modules with clearly defined layers of interfaces between

modules, making it easier to extend its capabilities beyond the present requirements to

suit the changing needs of the users. The MACE user interface is clearly separated from

the underlying collaboration processes. This user interface can be easily modified and

customized to the needs of a group of users without affecting the structure of the system.

The files editable by MACE are required to be saved in plain ASCII text format, making

them accessible by the user's favorite editor when the file is not shared.

The users should be able to get information on which user is accessing which

sections of the document. Users should be able to access the updates of other users, while

allowing for private edits by authors as an option. There should be different modes of

editing/viewing a file in MACE to cater to the specific needs of the users using the

system. These modes are discussed in detail in the design features section of Chapter 4.

We have briefly seen the requirements of the shared concurrent editor developed.

Now we discuss the design features of MACE in detail, which meet our requirements

specified.

4.3 Design

The MACE window appears as another resizable window on the user's screen,

which can be minimized or maximized. The user is free to move between his private









areas and his MACE window. The usernames of the people currently editing the file is

accessible by the user. The user to edit the same or different files can invoke multiple

MACE windows. The editor commands can be accessed by mouse click operations on

command buttons and menu items.

MACE has four modes of editing a file. The user can operate on a file in one of

following four modes. The four modes are shared read mode, snapshot mode, shared edit

mode and private edit mode. In addition to these a user can edit a file in the extra copy

editing mode which is discussed shortly.

In the shared 'Read' mode, the user can view the contents of the file without being

able to edit the file. In this mode the user's screen is refreshed with the committed updates

by other users periodically. All the users start in this mode initially. In the shared edit

mode, the user will first acquire a lock over a part of the file specified by the start and end

locations.

Once the user acquires a lock, he will be able to edit that part of the file. The user

has the option of making the edits private or shared. When the user makes his edit

private, updates will not be sent to the remote sites. In shared mode the updates are

automatically sent to the remote sites periodically. The user can lock only one section.

However, if the user desires to edit more than one section, multiple MACE windows can

be invoked on the same file.

In the snapshot mode, the user can request to see the snapshot of the screen of

another user. For this to be possible, the latter has to accept the request for snapshots. The

snapshot will be shown in a pop up window and the user cannot edit in this window.









Extra copy editing mode is used when the user wants to edit a section of the text

already locked by another user. The user invokes extra copy of the file and starts editing

the section of the file he wants to. The DCS voting mechanism Decision Support System

(DSS) [29] will be used to decide on which edit to finalize. Essentially two copies of the

file are created and the voting mechanism will help in resolving the copy to be used

further. If a user wants to synchronize with an extra copy being edited, the user can

invoke multiple MACE windows to keep track of all the different copies.

The EG of MACE is equivalent to zero bytes. The user can request a lock between

any two bytes of text in the file. If the user specifies the same byte as start and end

location, the lock area will be zero bytes initially. The size of a locked area can be

anything between zero bytes and the length of the file. In this case the CI can be infinity.

However there are other limitations on the number of users who can concurrently edit a

file. The prominent among the reasons is the network speed. We know that any network

is only as fast as its slowest link. It applies to MACE also. If there is a user editing a file

with a relatively slow network connection, the communication among all the edit

windows slows down considerably. To provide a considerable speed in updates, the

number of users editing that file should be minimal. Also some individual workstations

can have a limited number of open network connections. The number of users will also

be limited by this number. Theoretically any number of users will be able to edit a file

concurrently.

The UG of MACE is equivalent to one section of the text and that particular section

can be of any size, depending on the user's locked area. Updates are always sent as a









section of text. The locked section UG is the minimum granularity possible as the user

can change the text anywhere in the locked section.

The UF of MACE can be controlled by the user. MACE has a default periodic

frequency. The user can disable the default and make the updates user controlled. MACE

can potentially have a real-time frequency by making the frequency minimum. This will

make difference between periodic update frequency and real-time update frequency

insignificant.

The updates in MACE are completely controlled by the user's site. The updates of

remote sites are not automatically sent to the user's local MACE window. The updates

are requested by the user's site periodically. The contents of update will depend on the

portion of the screen the user is viewing at that time. The user site keeps track of which

parts of the file are being viewed by the user. As each section of a MACE file is no more

than a finite small size (further discussed in Chapter 5), the active section combined with

two or three contiguous sections will not be more than a finite amount in size. Hence the

set of active sections on a user's screen is limited. These active sections are continuously

changed as the user scrolls through the text.

When the user requests updates from a remote site, only the updates to active

sections are sought. This feature reduces the amount of data being transmitted between

remote sites. Consider the case of a number of users editing a very large file. If the whole

file is transmitted for every update, then there is high probability of increased network

latency. MACE ensures that transfer of complete text of huge files across network is

eliminated to a large extent.










MACE provides user awareness information in two forms. A user can request to

see a pointer to the location where another user is editing. This is called a tele-pointer. A

user can also point his mouse over a locked area to see who is editing that section. This

will help collaborators to communicate more effectively.




Applications
MACE, AN sharing, Wh iteboard





D-------- --------------------------------------

NTF ACS DSS CCS DFS



------_--------- -- 9
---------


TCP UDP DBMS



Figure 3. Architecture of DCS









4.4 Distributed Conferencing System

MACE is the concurrent text editor of DCS. It makes use of many features of DCS.

First the users in the MACE session are the users in the DCS conference. DCS provides

the access control facilities [27]. The DCS file system is used for the pool of MACE

editable files. The SCS [26] module ofDCS is used for secure communication among its

local and remote sites. MACE makes use of the DCS [28] voting mechanism. The DCS

discussion window can be used for asynchronous communication between the users

sharing a file. MACE provides a good application for session and artifact based

collaboration for joint authoring of text documents.

4.5 Architecture

The architecture of a collaboration aware application can take two forms. An

existing single-user application can be modified and enhanced to make it collaboration

aware. A number of systems used this process for the design of concurrent editors. This

method suffers from severe limitations, as the developer is constrained with the existing

system in many ways. Most editors are specific to one platform or the other. This is an

issue in developing a platform independent editor. We have opted to design the MACE as

an open system as it is easier and also can provide better base for later improvements and

enhancements.

The MACE uses process distribution among user's workstations minimizing the

workload on any one site. This architecture helps in minimizing network overhead.

4.6 Conclusion

MACE is designed as a platform independent concurrent editor with a minimum

editable granularity. MACE is the collaborative editing application for DCS and also

functions as an independent concurrent text editor.









The MACE editor should have minimum response time possible. MACE is

designed to ensure minimum communication over the network and is designed as a

modular concurrent editor to provide for further enhancements when needed.

Users need not explicitly start a session for concurrent editing, all the users editing

a file will be put in the same session by the application. MACE is designed to handle

unexpected system crashes and recover to the last committed state smoothly without user

intervention. The application provides awareness information of other users' actions in

the session through the use of tele-pointers and tooltip text on parts of the file.

MACE supports a number of editing modes for the user to chose. A user always

starts a session in a shared read mode. A user can chose to enter the edit mode by

acquiring a pair of locks. A user can also choose to view a snapshot of another user's

screen with the consent of the latter. The UG of MACE is equivalent to one section of the

text which is the part of the file editable by the user. MACE retrieves only the remote

updates which have a higher probability of being viewed by the user. The updates made

to the file which are not on user's screen are not retrieved, thus reducing the amount of

data transferred from remote site. MACE provides awareness information by displaying

users in the session along with tele-pointers of other users on request.

We have discussed the requirements and design for MACE in Chapter 4. In

Chapter 5 we look at the implementation details of MACE to achieve the described

design objectives.














CHAPTER 5
IMPLEMENTATION

We have seen the requirements of MACE and its design features in the Chapter 4.

In Chapter 5, the implementation details to meet the design features are discussed.

5.1 Introduction

MACE uses Java and RMI for implementing the system. Swing is used to design

the user interface of the editor. MACE is designed in four modules. The file manager acts

as the interface between the MACE editor and the file system. The edit manager acts as

the central coordinator for all the edit windows editing a particular file. There can only be

one edit manager per file with a number of edit windows for simultaneous editing. The

user interface module is the interface used for display and editing of a file.

MACE uses locking based concurrency control for concurrently editing a file. A

user has to acquire a pair of locks before he can start to make changes to the file. The edit

manager controls access to the parts of the file by granting locks to each user after

checking for conflicts.

The files in MACE are located in a distributed manner. Users can have files located

on their site or at remote sites. MACE has an inbuilt reliability and recovery mechanism

in case the edit manager crashes. The MACE uses a hierarchical order to decide the site

to start edit manager in the case of the original site crash. However, a crash at an edit

window site is treated as the user leaving the session.

MACE is connected to the DCS history versioning system to keep track of the

versions. This provides reliability to the MACE file system.









In the coming sections we look at the implementation features in detail.

5.2 Platform and Programming Language

The platform for the implementation has been chosen on the criteria of availability,

portability and ease of implementation. The DCS system is implemented in Java [29]

using RMI and Swing. MACE is also implemented in Java with the interface designed in

Java Swing. MACE uses RMI for communication between different sites. MACE uses

the SCS [26] module of DCS for secure communication between its remote sites.

5.3 Modules

The MACE implementation consists mainly of four packages: the File Manager

(FM), the Edit Manager (EM), Edit Window (EW) and the User Interface (UI). The FM

is the start up module to run when the MACE application is used. The EM and EW are

related to a particular session of a particular file. The UI is the MACE user interface

implemented in Swing. The design of MACE is based on MACE V 1.0 [1]. MACE V 2.0

is an enhancement of MACE V 1.0. The four modules are discussed in detail below.

5.3.1 File Manager

The FM in MACE is the file services daemon. FM is the interface for DCS file

system and is responsible for acquiring the file lists, both local and remote, available for

editing in MACE.

When a user selects a file to edit, FM searches its tables to verify if an EM for that

file is active. If an EM is already active then a new EW is created at user's site.

Otherwise both an EM and an EW are created at the user's site. This EM now becomes

the central point of communication for all EWs created for editing the particular file.

When the file is to be saved the EM communicates the contents of the file to FM.

FM is designed to interact with file system and save the file system. The FM is also









designed to retrieve different versions of a file from DCS history versioning system. This

may be done when a user requests to view a previous version of the file.




FM





EM
EM *


EW EW EW EW
EW EW EW EW


UI UI UI UI
UI UI UI UI


Figure 4. MACE architecture

The FM runs as a background daemon. The FM is displayed to the user with

another interface, an object of which is instantiated at the start of MACE application. The

interface helps the user in selecting a file for edit. The figure below shows the interface

for MACE File Manager.

5.3.2 Edit Manager

Each file that is edited is associated with an EM. EM acts as the central agent of

communication for all the EWs on a file. The EM ensures process synchronization and

consistency through serialization. It handles two forms of serialization: spatial and

temporal. Spatial serialization is performed with the use of locking mechanism. No two

users are allowed to edit the same portion of the file, thus ensuring spatial separation

between users' transactions. Temporal serialization is performed by maintaining FCFS







44



order of processing requests. The integrity of the file is maintained with the use of these


forms of serialization.


* !J i llg


M4 CE: A fine-grained Concurrent Tet Editor


11ew IF.li
|New rile


- Sveth Lcaionan nmeofyou M 4-I1C


Figure 5. MACE file manager.




As MACE is a distributed program, EM is not designed to permanently reside at


any one pre-determined site. EM will run on the site from where the first user invoked the


use of a file. The site hosting EM on a file can change for each session. When the user


site holding EM leaves the session, a new user site still using the file, will start running


the EM.


The EM controls the session. As the EM is the central point of communication, it is


designed to carry minimum load. EM is designed to carry what are called "administrative


Sm In 1|i i-l vi
i13 V.I 1 %li





I RulM.l P1'fl

FIli e11 .1- +: |
tlip q*. IVIIw: I. l-lipq


I


s~z c 1IIEII I









responsibilities", like granting locks, granting entry to new users and maintaining the

most recent copy of the file. EM is also responsible for sending notifications to all EW

sites when an event occurs. The EM is not involved in actual text edit in anyway. The

user performs the actual updates on a file at the EW.

5.3.3 Edit Window

The EW runs at the user's site. Each user editing a file will have one EW running

on his machine. The user can invoke more than one EW if one is editing different parts of

the file.

As the EW runs on the local machine, it is designed to accept the maximum

processing load of editing and maintaining updates on the file. It is responsible for

communication between the user's interface and EM of the file. It is responsible for

sending and receiving updates on the file with the EM and processing lock requests. EW

daemon receives event notifications from EM and takes appropriate action. The

notifications include events; lock granted, lock release, new user and user exit.

The UI and EW are tightly coupled. If the user has chosen private edit, the EW

sends the update on the section being edited by the user to EM when the user chooses to

commit. If the user is in auto-commit mode, the EW periodically sends the latest updates

on the section to the EM. The EW keeps track of the text updates of the user, the active

sections on user screen and the edit mode of the user. EW periodically retrieves the most

recent version of text of sections active on user's screen from the EM. To reduce the

amount of data retrieved, EW retrieves only the sections that are being edited by some

other user.

Different sites have different network bandwidths. It is inappropriate to impose the

same communication overhead on all sites irrespective of their network speeds. MACE








46



provides a facility for user to specify the periods of time one wants to send an update and


receive updates. EW retrieves these settings from user preferences and sets the update


frequency accordingly. This will help in reduction of excessive communication for users


with slow network speeds. In other instances users with very good broadband


connections can set the update frequency to a negligible amount of time. This will allow


them to have a virtual real-time connection to the other users.


package EM AIo C,

in'rt FM* ;
ir'port EW.*;
iniptrt Stubs.*


import java.util.*
in'poI java.rmi.*;
import java.rmi.server.*;
import java.io.*;
locally
public class editManager extends UnicastRemoteObject
implements eminterface


listFSEM mainList;
int version ;
String fileName;
editWindowList userList
fmlnterface thisManager ;
Timer fileSaveTimer = new Timer ;

String editManagerName
eminterface thislnterface

public editManager 0 throws RemoteException

super ;



/" This method is the constructor of Edit Manager
*@param String String fileManager int
-I
public eminterface constructor(String FileName, String fileContents, fmlnterface FileManager, int serial



Figure 6. MACE edit window


5.3.4 User Interface


The UI module is the face of MACE. The UI communicates only with the EW in


the user's site. The UI is designed to be user-friendly. The user can find which sections of









the text are locked and by whom. The text of the file is displayed in three different colors

to the user. Each color represents different access rights on that section of that text. One

color represents sections of text locked by other users. A second color represents sections

of text locked by this particular user, which is editable. The third color represents sections

of text, which are not locked by any one.

To request a lock the user specifies the start location by clicking his mouse over

that location. Then he clicks the start of edit area button. The same is done to specify the

end location. Once the lock is granted the locked area is displayed in a different color and

user can start editing in that section.

Periodically the EW refreshes the user's screen with the latest updates received.

When the user scrolls his mouse on the section of text locked by others, the information

of the user locking that section is displayed as a tool tip. This enables the user to

interactively find the user editing a particular section.

The UI is designed to keep track of the active sections on the user's screen. As the

user scrolls through the file, the sections are updated to active or inactive, as may be the

case. Whenever there is a change in the text of a section, the new text is displayed to the

user's screen without causing any hindrance to the work the user is doing.

A user can, upon request see the pointer to the location where the other user is

editing. This is done in two steps. First the user initiates a request for the tele-pointer

from another user; the latter user's screen displays the request. On approval a real-time

connection is established between the two users. The first user can then see the changes

to the mouse and key cursor movements of the second user when he wishes. If there has

to be two way displays of tele-pointers, the second user follows the same process as first









user and gets his approval for tele-pointers. All this communication is performed directly

between the users' sites without the involvement of EM. This reduces any

communication that may have additionally gone through the EM.

5.4 Concurrency Control

MACE uses locking as the means for collision control. The user has to acquire a

lock before he can start editing a file. The serialization is maintained in two forms:

temporal and spatial as discussed previously.

Initially the user is in the read mode. The user has to select start and end locations

of the area he wants to edit before he can request a lock. The EW verifies if any one else

locked the area. If not, the request is sent to the EM. If the lock request is granted, the

EM increments its version number and then notifies all the EWs of the new lock. All the

EWs will lock their sections and increment their version numbers.

After acquiring the lock, the user can edit the section he locked until he releases the

lock by himself. The updates are sent to EM periodically unless the user selects private

edit option. In that case, the updates are sent whenever the user commits the changes.

Once the user releases his lock, the section is opened for lock requests from other users.

To avoid race condition in lock requests and in all communications, the EM

maintains a version number. All the EWs maintain a version number of their own. If the

version numbers do not match in any communication, the specific request is denied. The

EW has to synchronize itself again with EM. For every lock request the version number

is incremented.

The version numbers are changed in case of five events; on user entry, on user

leaving, on new locks, lock releases and on initiating new EM. The occurrence of any of

these events is broadcast without delay to all user sites. A user cannot make any









successful communication during a broadcast as the version numbers between user site

and EM do not match. The user will resend the communication after he receives the

previous broadcast.

5.5 Replication and Recovery

The EM maintains a list of users accessing the file. Whenever a new user enters the

session, the details are added to the list. This list is fully replicated at all sites. This list is

useful in case of a failure.

Whenever user commits his changes to the file, the updates are sent to the EM. This

makes sure that the EM always has the latest committed copy of the file. All the updates

to the EM are sent to at least two other EWs, thus ensuring that three sites have the latest

committed copy at any time.

If an EW crashes at any time, the EM tracks the failure. If the EW does not respond

with an acknowledgement for a notification more than once, then it is construed as an

EW failure. Then the locks held by the user are released and the user is removed from the

list. Handling failure of an EW is thus straightforward, but if an EM fails then we need to

have an elaborate mechanism to handle the situation.

All the EWs have the user list. This list is consistent across all sites as any changes

to the list are propagated immediately. In the event of EM not responding to any

communication from an EW, the EW after verifying that EM is inaccessible will initiate a

process of instantiating a new EM. The first EW alive in the users list will be requested to

declare itself as the new EM. This EW in turn invokes a new EM and notifies all other

users in the user list of the change of EM. Each EW then sends an acknowledgement

back accepting the new EM. Now the new EM will manage the session as the central

agent. Before initiating process for new EM, the EW checks with all other EWs in touch









to see if any EW has an active connection with EM. This ensures that unless the EM lost

communication of all users, there will not be a new EM at another site.

The above recovery mechanism is ineffective if the EM is still alive and a subset of

EWs loses connection to EM but not between themselves. Now, after this process, there

will effectively be two independent EMs at the same time without communication

between each other. This can happen if a subnet has its network connection cut from the

rest of the world in the middle of a session. The EWs in the subnet have a different EM

than the rest of the world. In this event the EM having access to the site where the file

resides will write the original copy of the file. In most common cases the above

mechanism will be sufficient for maintaining a smooth and reliable recovery mechanism.

This will ensure that users will not lose their saved changes in case of an

unexpected EM crash.

5.6 Conclusion

MACE is implemented in Java, RMI and Swing. The choice of the programming

language is made in view of its platform independence and to make the collaboration

easier with DCS, which is implemented using Java.

MACE design is split into four modules. The FM is the file manager interface

dealing with the file system of the native operating system or the DCS File System. A

user starts his MACE system with the FM. The EM is the central coordinator for all the

edits on a MACE file. Every file in MACE has one and only one EM running at any time.

EW is the module which runs at each site editing a MACE file. Each user has his own

edit window and all the edit windows coordinate with the EM. If a user has more than

one file open for edit, then he will have that many number of edit windows running on his









site. The user interface module controls the display area of the user site. This module

communicates only with the EW of the particular file on the site.

The files in MACE are distributed across sites. MACE has an inbuilt recovery

mechanism in case of a crash at an EM site which is central to the session of editing a

file.

MACE uses locking mechanism for collision avoidance among different edits on a

file. The EM controls access to the sections of a file by all the edit windows. This will

ensure the consistency of the file and serializability of the transactions.

Chapter 6 concludes this thesis with a discussion on future work and by

highlighting the unresolved issues in this version of MACE.














CHAPTER 6
CONCLUSION

In the conclusion of this thesis we shall review what we have discussed and analyze

MACE to look at some of the improvements possible for MACE.

6.1 Introduction

MACE is a fine-grained lock based concurrent text editor. As group activities have

come to dominate the modern workplace, the need for collaborative editing tools is more

than ever. MACE version 1 was developed at the University of Florida in 1991. This

version of MACE is an enhancement over MACE Version 1.0 with the system

completely redeveloped.

Any collaborative editing system is desired to have a low granularity and high

concurrency index. A concurrency control mechanism should have mechanisms to ensure

file consistency, transaction serializability and avoid collisions. MACE uses a locking

based approach to implement its concurrency control mechanism.

We have reviewed a number of synchronous and asynchronous collaborative

editors in comparison with MACE. This has helped us define the desirable characteristics

of the system being developed. MACE is designed as an open system to provide for later

enhancements to the application.

MACE implementation is completed in four modules. Each of the modules has

clearly defined interfaces with the other modules. This makes it easier to modify or

enhance the available code.









The development of MACE required that the system can be run on any platform

and the development is modular. MACE used Java and RMI for the implementation of

the system. MACE has a fault tolerance mechanism to ensure that edits are not lost due to

unexpected crashes and the session is not interrupted.

We have looked at the features of MACE in brief. Now we look at some of the

deficiencies of MACE in terms of conceptual and design issues.

6.2 Conceptual Issues

Conceptual issues are issues in concurrent editing that have not been satisfactorily

resolved in the development of MACE.

6.2.1 Commenting and Annotation

A common requirement of concurrent text editors would be the feature supporting

commenting and annotation. When a number of authors are making modifications to a

document, a facility to keep track of changes and the reasons for those changes would be

very helpful. Commenting would be helpful in authors recording the reasons for making

specific changes to the document. Annotation would be useful for authors to provide

hyper linked information.

Commenting would require a separate storage structure for the document. The

separate storage structure is required to distinguish between the comments and original

text. This would require that documents be stored in a specialized format readable by

MACE application. This would contradict with the other requirement that the documents

be readable by heterogeneous editors.









6.2.2 Access Rights

Presently the only access rights provided by MACE are read, update and no access.

A user can update and modify any part of the file if he has an update right. Similarly, a

user can read any part of the file if he has a read access right.

But real life co-authoring situations require more fine-grained access control.

Authors may want to make their changes to the file permanent, so that other users will

not be able to modify that part of the file further. Some users may want parts of the file to

be confidential. While still other users may want to specify which users can read the

changes they made and which users cannot. These access rights if implemented would

throw up more issues to deal with. The primary issue being the decision process of who

gets those access rights. There should be a fair process of relegating access rights. If there

are users who undo the changes made by the other users, then shared editing will be

conflict ridden. No user can ensure that their changes will remain permanent. Although

this issue is not resolved to satisfaction, the history versioning system of MACE is

helpful.

6.2.3 Usage Analysis

A proper analysis of MACE calls for the gathering and analysis of statistics on the

usage of the system. These statistics may help us in tailoring the system to suit the exact

needs of the users. A proper analysis is required to make MACE even more useful for the

users.

6.3 Design Issues

Design Issues are the issues in implementation that have not been resolved

satisfactorily in this version of MACE.









6.3.1 Decision Support

In the present version, the decision support for MACE is provided by the DCS.

When MACE is used as a stand-alone editor it does not have a decision support system.

That feature would be helpful for stand-alone editors as well.

6.3.2 Extra Copy Editing

Extra copy editing in the present version of MACE is essentially a creation of two

different copies of the file with the same name. The section in conflict should have two

different copies. But, the sections of the file not in conflict should be common to both the

files. MACE does not support this feature.

6.3.3 Replication Strategy

The file in MACE is fully replicated in at most three sites. These three sites are

right now chosen on the basis of the order of their entry into session. While the

implementation of this method is easier and relatively efficient, there are some flaws with

this implementation. If all the first three sites editing a file are located in one LAN, then a

failure of the LAN network connection will render the whole session a failure. Similarly,

if one of the first three sites has a very low network bandwidth, then the whole

communication of the session is slowed down.

There can be a better strategy of selecting the sites for replication of the file. This is

yet to be implemented.

6.4 Future of MACE

This implementation of MACE has been mainly designed with the ideas of the

DCS team and some research done by other institutions before. There are very few

research institutions that tried to gather data regarding usage and target groups of shared

editors. We plan to put MACE into use and collect data regarding the patterns of its









usage. The next step would be to provide enhancements for MACE that are tailored to the

needs of the user with prior knowledge of the patterns of usage.

There are a variety of applications for a shared editing tool. Each application

requires customized features. Like joint software development would involve syntax

checking tools in the editors and co-authoring documents would require support for

annotation. A future work on MACE may involve customization of the application for

different user communities.

6.5 Conclusion

This thesis presented the design and implementation of MACE, the Mother of All

Concurrent Editors version 2. This implementation is a step towards the realization of the

goal of achieving a fine-grained, platform independent and user-friendly concurrent

editor.















LIST OF REFERENCES


1. Pelimuhandiram H., and Newman-Wolfe R. E., MACE: A Fine Grained
Concurrent Editor, Conference Proceedings on Organizational Computing Systems,
Atlanta, GA, November 991, pp. 240-254.

2. Olson J., Olson G., Storrosten M., and Carter M., How a Group-Editor Changes the
Character of a Design Meeting as well as its Outcome, Proceedings of the 1992
ACM Conference on Computer-Supported Cooperative Work, Toronto, Canada,
November 1992, pp. 91-98.

3. Stefik M., Bobrow D. G., Lanning S., Tartar D., and Foster G., WYSIWIS Revised:
Early Experience with Multi-User Interfaces, Proceedings of the Conference on
Computer Supported Cooperative Work, Austin, TX, April 1986, pp. 276-290.

4. Newman-Wolfe R. E., Ramirez C. L., Pelimuhandiram H., Montes M., Webb M.,
and Wilson D. L., A Brief Overview of the DCS Distributed Conferencing System,
Proceedings of the Summer 1991 USENIX Conference, Nashville, TN, June 1991,
pp. 437-452.

5. Neuwirth C. M., Kaufer, D. S., Chandhouk R., and Morris J. H, Issues in the
Design of Computer Support for Co-Authoring and Commenting, Proceedings of
the Conference on Computer-Supported Cooperative Work, Los Angeles, October
1990, pp. 183-195.

6. Edwards W. K., Policies and Roles in Collaborative Applications, Proceedings of
the 1996 ACM Conference in Computer-Supported Cooperative Work, Boston,
April 1996, pp. 11-20.

7. Oszu T. M., and Valduriez P., Principles of Distributed Database Systems,
Prentice-Hall, Englewood Cliffs, NJ, 1999.

8. Coulouris G. F., and Dollimore J., Distributed Systems, Addison-Wesley
Publishing Company, Avon, UK, 2001.

9. Sullivan T. P., A Dynamic Two Phase Locking Concurrency Control Protocol,
University of Florida, Gainesville, Master's Thesis, 1989.

10. Lantz K. A., An Experiment in Integrated Multimedia Conferencing, Proceedings
of the Conference on Computer Supported Cooperative Work, Austin, TX, April
1986, pp. 267-275.









11. Ellis C. A., Gibbs S. J. and Rein G. L., Design and Use of a Group Editor, MCC
Technical Report Number STP-263-88, 1989.

12. Greif I., and Sarin S., Data Sharing in Group Work, Proceedings of the Conference
on Computer Supported Cooperative Work, Austin, TX, April 1986, pp. 175-183.

13. Greif I., Seligar R., and Weihl W., A Case Study of CES: A Distributed
Collaborative Editing System Implemented in Argus, IEEE Transactions on
Software Engineering, Volume 18, Number 9. September 1992, pp. 827-839.

14. Leland M. D. P., Fish R. S., and Kraut R. E., Collaborative Document Production
Using Quilt, Proceedings of the Conference on Computer-Supported Cooperative
Work, Portland, OR, ACM, September 1988, pp. 206-215.

15. Koch M., and Koch J., Using Component Technology for Group Editors The
IRIS Group Editor Environment, Proceedings of Workshop on Object-Oriented
Groupware Platforms, Lancaster, UK September 1997, pp. 44-49.

16. Koch M., Design Issues and Model for a Distributed Multi-User Editor, Institut fur
Informatik, Technische Universitat Munchen, Germany, 1995, pp. 359-378.

17. Borghoff M. U., and Teege G., Applications of Collaborative Editing to Software
Engineering Projects, Institut fur Informatik, Technische Universitat Munchen,
Germany, 1993.

18. Whalen T.J., Design Issues for an Adaptive Mobile Group Editor, Master's Thesis,
University of Waterloo, Waterloo, Ontario, Canada, 1997.

19. Begole J.M., Flexible Collaboration Transparency: Supporting Worker
Independence in Replicated Application Sharing Systems, Ph. D. Dissertation,
Virginia Polytechnic Institute and State University, Blacksburg, VA, 1998.

20. Zafar A., NetEdit: A Collaborative Editor, Master's Thesis, Virginia Polytechnic
Institute and State University, Blacksburg, 2001.

21. Knister M., and Prakash A., DistEdit: A Distributed Toolkit for Supporting
Multiple Group Editors, Proceedings of the Conference on Computer Supported
Cooperative Work, Los Angeles, October 1990, pp. 343-355.

22. Lewis B., and Hodges J., Shared Books: Collaborative Publication Management for
an Office Information System, Conference Sponsored by ACM SIGOIS and
IEEECS TC-OA on Office Information Systems, Palo Alto, CA, March 1988, pp.
197-204.

23. Dourish P., and Bellotti V., Awareness and Coordination in Shared Workspaces,
Proceedings of ACM Conference on Computer Supported Cooperative Work,
Toronto, Canada, November 1992, pp 107-114.









24. Chabert A., Grossman E., Jackson L. S., Pietrowiz S. R., and Seguin C., Java
Object-Sharing in Habanero, Communications of the ACM, June 1998/Volume 41,
Number 6, pp. 69 -76.

25. Pelimuhandiram H., MACE: The Mother of All Concurrent Editors, Master's
Thesis, University of Florida, Gainesville, 1991.

26. Aringunram R., Secure Communication Services for Distributed Conferencing
System, Master's Thesis, University of Florida, Gainesville, Fl, 2002.

27. Manian V., Access Control Model for Distributed Conferencing System, Master's
Thesis, University of Florida, Gainesville, Fl, 2002.

28. Kakarparti A., Distributed Support Service for Distributed Conferencing System,
Master's Thesis, University of Florida, Gainesville, Fl, 2002.

29. Naughton P., and Schildt H., The Complete Reference- Java 2, Berkeley, CA, Tata
McGraw-Hill, 2002.















BIOGRAPHICAL SKETCH

Vijaya Rangadham Komaragiri was born in the city of Hyderabad, Andhra Pradesh,

India. He grew up in Vikarabad, Andhra Pradesh, India, and completed his elementary

and high school in Vikarabad. He then went to Hyderabad to complete his Bachelor of

Engineering in Computer Science and Engineering from Osmania University, Hyderabad.

He completed his undergraduate degree in 2001 and went on to the University of Florida

to pursue a Master of Science degree in computer engineering, which he completed in

2004.