enabling realtime collaborative data-intensive web ... ·...

Fakultät für InformatikDer Technischen Universität München

Master’s Thesis in Informatik

Enabling realtime

collaborative data-intensive

Web Applications - A case

study using server-side

JavaScript

Tobias Höfler

Fakultät für InformatikDer Technischen Universität München

Master’s Thesis in Informatik

Enabling realtime collaborative

data-intensive Web Applications - A case

study using server-side JavaScript

Realisierung von Echtzeit-Kollaboration

in datenintensiven Web Applikationen -

Eine Studie mit serverseitigem JavaScript

Author: Tobias HöflerSupervisor: Prof. Dr. rer. nat. Florian MatthesAdvisor: Sascha Roth, M. Sc.Submission Date: 15.05.2013

I assure the single handed composition of this master’s thesis only supportedby declared resources.

München, 15.05.2013

Tobias Höfler

Abstract

The purpose of this Thesis is to analyze, how realtime collaborative data-intensive web applications can be enabled with particular reference to server-side JavaScript.First, a survey was conducted to analyze the role of server-side JavaScript inorganizations. It turns out, that the general satisfaction with JavaScript isquite high and Node.js, a prominent example of server-side JavaScript, is al-ready widely known. It is shown, that Node.js is typically used to implementweb applications. The participants additionally confirm, that Node.js is al-ready enterprise ready and that its importance will rise in future.Furthermore, a collaborative editor is designed, that enables the collabora-tive editing of text and provides collaborative features like chatting or invitingother users to work collaboratively on the same document. It follows theprinciples of the realtime architecture, which is presented in this Thesis. Itis shown, that this architecture is a good fit for enabling realtime collabora-tion. In addition, this design is implemented prototypically with technologieslike Ember.js, Node.js, socket.io and share.js. At last, this Thesis describesapproaches to enhance the collaboration to rich text and arbitrary models.

I

Contents

List of Figures V

List of Tables VII

Listings VIII

1. Introduction 1

2. Foundations 42.1. Collaborative Writing . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1. A taxonomy for collaborative writing strategies . . . . . 52.1.2. Operational Transformation . . . . . . . . . . . . . . . . 8

2.2. Transport Technologies . . . . . . . . . . . . . . . . . . . . . . . 122.2.1. Polling and Piggibacking . . . . . . . . . . . . . . . . . . 142.2.2. Comet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3. Flashsockets . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.4. HTML5 Websockets . . . . . . . . . . . . . . . . . . . . 212.2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3. Realtime Web Applications - A Market Analysis . . . . . . . . . 242.3.1. Google Docs . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.2. Etherpad (lite) . . . . . . . . . . . . . . . . . . . . . . . 252.3.3. ShowDocument . . . . . . . . . . . . . . . . . . . . . . . 262.3.4. Zoho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.5. Web IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.6. Feature Comparison and Summary . . . . . . . . . . . . 28

2.4. Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.5. Tricia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3. On the Role of Server Side JavaScript in Organisations 333.1. Survey Related Work . . . . . . . . . . . . . . . . . . . . . . . . 333.2. Survey Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

II

Contents

3.3. Survey Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3.1. Results about JavaScript . . . . . . . . . . . . . . . . . . 393.3.2. Results about Node.js . . . . . . . . . . . . . . . . . . . 463.3.3. Background Information about the Companies . . . . . . 53

3.4. Survey Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 53

4. Design of the Collaborative Editor 554.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.1.1. User-centric use cases . . . . . . . . . . . . . . . . . . . . 564.1.2. Document-centric use cases . . . . . . . . . . . . . . . . 594.1.3. Dashboard-centric use cases . . . . . . . . . . . . . . . . 62

4.2. The Realtime Architecture . . . . . . . . . . . . . . . . . . . . . 634.3. Architectural Overview . . . . . . . . . . . . . . . . . . . . . . . 644.4. Design of the Client . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.4.1. Rich Internet Applications . . . . . . . . . . . . . . . . . 654.4.2. Client Components . . . . . . . . . . . . . . . . . . . . . 65

4.5. Design of the Server . . . . . . . . . . . . . . . . . . . . . . . . 774.6. Initial Client-Server Communication . . . . . . . . . . . . . . . 794.7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5. Prototypical Implementation of the Collaborative Editor 815.1. Shared Third-Party Libraries . . . . . . . . . . . . . . . . . . . 81

5.1.1. socket.io . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.1.2. share.js . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.2. Prototypical Implementation of the Client . . . . . . . . . . . . 865.2.1. Modularisation and libraries . . . . . . . . . . . . . . . . 865.2.2. User Interface with Twitter Bootstrap and Ember.js . . . 895.2.3. Collaborative Editor Details . . . . . . . . . . . . . . . . 965.2.4. Implementation of the Editor Overview . . . . . . . . . . 102

5.3. Integration into Tricia . . . . . . . . . . . . . . . . . . . . . . . 1035.4. Prototypical Implementation of the Server . . . . . . . . . . . . 105

5.4.1. Implementation of the Server Components . . . . . . . . 1055.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6. Enhancing Collaboration 1156.1. Google Wave Operational Transformation . . . . . . . . . . . . 1156.2. Collaborative Editing of arbitrary Models . . . . . . . . . . . . . 118

III

Contents

6.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7. Conclusion and Outlook 121

Bibliography 123

Appendix A. Survey 131A.1. Survey Question . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

A.1.1. Java Script . . . . . . . . . . . . . . . . . . . . . . . . . 131A.1.2. Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . 135A.1.3. Your Company . . . . . . . . . . . . . . . . . . . . . . . 138

A.2. General Statements about JavaScript . . . . . . . . . . . . . . . 140A.3. General Statements about Node.js . . . . . . . . . . . . . . . . . 141

Appendix B. Implementation of the collaborative editor 142B.1. Supported browsers by socket.io . . . . . . . . . . . . . . . . . . 142

B.1.1. Desktop Browsers . . . . . . . . . . . . . . . . . . . . . . 142B.1.2. Mobile Browsers . . . . . . . . . . . . . . . . . . . . . . 142

B.2. Third party libraries used by the client . . . . . . . . . . . . . . 143

IV

List of Figures

2.1. Overview of Collaborative Writing Strategies . . . . . . . . . . . 52.2. Group Single Author Writing . . . . . . . . . . . . . . . . . . . 62.3. Sequential Writing . . . . . . . . . . . . . . . . . . . . . . . . . 62.4. Parallel Writing . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5. Horizontal-division Writing . . . . . . . . . . . . . . . . . . . . . 72.6. Stratified-division Writing . . . . . . . . . . . . . . . . . . . . . 72.7. Reactive Writing . . . . . . . . . . . . . . . . . . . . . . . . . . 82.8. Exemplary scenario to show the basic OT idea . . . . . . . . . . 92.9. Operational Transformation - Operation Context . . . . . . . . 102.10. Important Developments for realtime Web Applications . . . . . 122.11. HTTP Communication process . . . . . . . . . . . . . . . . . . 132.12. Polling Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.13. Comet Communication Process . . . . . . . . . . . . . . . . . . 162.14. WebSockets vs. Polling . . . . . . . . . . . . . . . . . . . . . . . 232.15. Screenshot of Google Docs . . . . . . . . . . . . . . . . . . . . . 242.16. Screenshot of Etherpad lite . . . . . . . . . . . . . . . . . . . . . 252.17. Screenshot of ShowDocument . . . . . . . . . . . . . . . . . . . 262.18. Screenshot of Zoho . . . . . . . . . . . . . . . . . . . . . . . . . 272.19. Screenshot of cloud9 IDE . . . . . . . . . . . . . . . . . . . . . . 282.20. Architecture of a typical Web Application implemented in Tricia 31

3.1. Survey Results - The average volume of code in JavaScript . . . 393.2. Survey Results - Judgements about JavaScript Syntax . . . . . . 433.3. Survey Results - Statements about JavaScript related to main-

tenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4. Survey Results - General statements about JavaScript . . . . . . 463.5. Survey Results - Beginning of the projects . . . . . . . . . . . . 483.6. Survey Results - Statements about Node.js . . . . . . . . . . . . 51

4.1. Use Cases of the collaborative editor . . . . . . . . . . . . . . . 56

V

List of Figures

4.2. Fundamental architecture of the collaborative editor . . . . . . . 644.3. Components of the client . . . . . . . . . . . . . . . . . . . . . . 664.4. Static Wireframe of the User Interface . . . . . . . . . . . . . . 674.5. The lifecycle of the client . . . . . . . . . . . . . . . . . . . . . . 684.6. ERD for Documents . . . . . . . . . . . . . . . . . . . . . . . . 694.7. ERD for Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.8. ERD for ChatConversations . . . . . . . . . . . . . . . . . . . . 704.9. User-Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.10. Chat-Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.11. Application-Controller . . . . . . . . . . . . . . . . . . . . . . . 724.12. Review-Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 724.13. Documents-Controller . . . . . . . . . . . . . . . . . . . . . . . 734.14. Basic Process of collaborative editing . . . . . . . . . . . . . . . 774.15. Components of the server . . . . . . . . . . . . . . . . . . . . . 784.16. Sequence Diagram for the integration of new users . . . . . . . . 79

5.1. Modules and libraries with their dependencies . . . . . . . . . . 865.2. The Collaborative Editor Start Page . . . . . . . . . . . . . . . 935.3. The OperationWrapper class . . . . . . . . . . . . . . . . . . . . 1005.4. The Editor in Action . . . . . . . . . . . . . . . . . . . . . . . . 1015.5. Exemplary Editor Overview . . . . . . . . . . . . . . . . . . . . 1035.6. Interaction workflow with Tricia . . . . . . . . . . . . . . . . . . 1045.7. Server Components with major third-party libraries . . . . . . . 1065.8. The Document Manager . . . . . . . . . . . . . . . . . . . . . . 110

6.1. Google Wave Items . . . . . . . . . . . . . . . . . . . . . . . . . 116

VI

List of Tables

2.1. Ready States of the XMLHttpRequest Object . . . . . . . . . . 192.2. Summary about the collaboration tools and their features . . . . 29

3.1. Survey Design - Organizations by industry sector . . . . . . . . 373.2. Survey Design - Participants by job title . . . . . . . . . . . . . 383.3. Survey Design - Typical kind of projects within the organizations 383.4. Survey Results - The usage of editors for JavaScript . . . . . . . 403.5. Survey Results - JavaScript testing frameworks . . . . . . . . . 453.6. Survey Results - Context of the Node.js projects . . . . . . . . . 473.7. Survey Results - Number of people within projects . . . . . . . 473.8. Survey Results - Kind of projects . . . . . . . . . . . . . . . . . 483.9. Survey Results - Usage of frameworks on top of Node.js . . . . . 50

4.1. Incoming events to the clients within the IO component . . . . . 744.2. Emitted events by the IO component . . . . . . . . . . . . . . . 75

5.1. Methods of the Share.js document-object . . . . . . . . . . . . . 97

6.1. Most important operation components in Google Wave . . . . . 117

B.1. Supported Desktop Browsers by socket.io . . . . . . . . . . . . . 142B.2. Supported Mobile Browsers by socket.io . . . . . . . . . . . . . 142B.3. Third party libraries used by the client . . . . . . . . . . . . . . 143

VII

Listings

2.1. Example messages from the server . . . . . . . . . . . . . . . . . 182.2. An usage example for WebSockets . . . . . . . . . . . . . . . . . 21

5.1. socket.io example from the server . . . . . . . . . . . . . . . . . 825.2. Code snippet that shows the usage of rooms . . . . . . . . . . . 835.3. Client-Server communication with the streaming protocol . . . . 845.4. Client-Server communication - A new Client connects . . . . . . 855.5. Exemplary definition of the emberUI module . . . . . . . . . . . 875.6. RequireJS configuration . . . . . . . . . . . . . . . . . . . . . . 885.7. The application-template . . . . . . . . . . . . . . . . . . . . . . 905.8. Router states . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.9. Review Route with post processing . . . . . . . . . . . . . . . . 945.10. Extract out of the Review Controller . . . . . . . . . . . . . . . 955.11. Extract out of the review-view . . . . . . . . . . . . . . . . . . . 955.12. KeyUp-listener for recognising changes . . . . . . . . . . . . . . 985.13. Span-Element for user-specific cursors . . . . . . . . . . . . . . . 985.14. CSS for the overview . . . . . . . . . . . . . . . . . . . . . . . . 1025.15. Includes Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.16. Multiplexing of the socket.io communication channel . . . . . . 1085.17. Needed options for share.js . . . . . . . . . . . . . . . . . . . . . 1095.18. Key schema of the key-value store . . . . . . . . . . . . . . . . . 1105.19. Access Tricia to fetch all documents . . . . . . . . . . . . . . . . 111

6.1. Exemplary Google Wave Operation . . . . . . . . . . . . . . . . 117

VIII

1. Introduction

The Internet is important and a necessary part of our lives. A study of Ger-many’s National Association for Information Management, Telecommunicationand new Media (BITKOM) showed, that more than the half of the germanpopulation cannot imagine a life without the web1.A major reason for this is the changing interaction model of the Internet. Inthe past it was website-centric. A user, interested in a particular information,started the browser and opened a web-page to retrieve them. To collaborateon an online forum, she filled a form within a website and submitted the newlyproduced information. The website itself was the central part of the interac-tion and provided mostly a static set of content. This model shifted to a usercentered one, whereas every aspect of the interaction starts and ends at theuser. The content itself is not defined by the website any more but rather bythe users. They define the information they are interested in and get informedwhen they occur so which leads to a necessity of sending the data actively tothe users. This paradigm-shift can be seen through the whole Web. Prominentexamples are social networks like Facebook or Twitter. [Bu11a] showed thatone fourth of the internet users are using their favorite social network betweenone and two hours per day and even eleven percent use them more than twohours per day. Therefore, social networks play an important role in our lives,which actually a clear example for the user centric interaction model. Thedevelopment of mobile applications running on a smartphone is another exam-ple. The applications send their information directly to the user, respectivelythe smartphone. This model shift also leads to a realtime user experience,as the user receives information when they occur, instead of looking manu-ally for them2. [Is11] even describes these types of applications with the term“Data-Intensive Real-Time Applications” (DIRT) which was coined by BrianCantrill, Vice President of Engineering at Joyent Inc. These applications havein common, that there is a lot of data to be processed and additionally, the

1cf. [Bu10]2cf. [Ro10, p. 2]

1

1. Introduction

users need to be notified about them in realtime which is the case for examplefor Twitter or chat applications3.

For the realization of web applications, JavaScript plays an important role.Gartner Research denotes JavaScript in an analysis of 2013, as a “safe and pre-ferred (virtually unavoidable for Web projects) option for nearly all nontrivialWeb application development efforts” and advices developers focusing on next-generation HTML5 to “build a deep knowledgebase surrounding JavaScript tobe successful”4. Also other sources show the importance of JavaScript. Itis, for example, the most popular programming language at GitHub5 and itis placed within the top 20 of O’Reilly Publishing’s computer books sales in2012 with a steadily increasing volume since 20046. JavaScript itself mostlyruns in browsers, interpreted by browser-specific JavaScript interpreters. Al-beit recent trends move JavaScript to server-side application development7. Aprominent example for this trend is Node.js8. Its event-driven approach makesit attractive for server programming and the handling of a lot of concurrentconnections, which is important especially for realtime applications9. Further-more, it provides a variety of different third-party packages through its ownpackage manager. Nevertheless, Node.js is still a quite young project; it evendid not mature to a stable 1.0 release.

The rise of the Internet’s user-centric interaction model with its realtime char-acteristics and the emerging technology of server-side JavaScript, leads to themain research question of the Thesis:

Is it possible to enable realtime collaborative data-intensive web applicationswith server-side JavaScript efficiently?

This question implies whether the application of server-side JavaScript is usefulfor this scenario and if it can be used in enterprises, yet. Furthermore, thereis the necessity to investigate in the feasibility of using server-side JavaScriptto enable realtime collaboration.

3cf. [Is11]4cf. [Ga13, p. 31]5cf. [Gi13]6cf. [Ga13, p. 30]7cf. [Ri10, p. 1]8cf. [Jo13a]9cf. [Is11]

2

1. Introduction

To analyze these questions, this Thesis is structured in the following way.Chapter 2 describes the fundamentals, needed for the Thesis, including an in-troduction of collaborative writing, different transport technologies and Node.js.For analyzing the role of server-side JavaScript in organizations and to assessits enterprise readiness, a survey was conducted. The results of it are presentedin Chapter 3.In Chapter 4, a design for a collaborative editor is developed to show, whattypical design decisions are made for realtime collaborative web applications.Following this design, a prototypical implementation of this tool is presentedin Chapter 5 to analyze the feasibility of implementing such an applicationwith Node.js.Chapter 6 discusses methods to work collaboratively on arbitrary models topresent a way of enhancing collaboration to more complex scenarios. At last,Chapter 7 gives a conclusion and shows topics for further research.

3

2. Foundations

This chapter builds the theoretical foundation for this Thesis. Section 2.1introduces collaborative writing and presents the current industry standardtechnology for helping to enable collaboration within applications. Technically,there are some special requirements for realtime web applications. Section 2.2introduces the underlying transport technologies that are necessary for realtimecommunication. For getting an overview about the current market situationof realtime web collaboration tools, Section 2.3 presents a market analysis andcompares some of the current tools. At last Section 2.4 introduces Node.js, acurrently emerging technology using server-side JavaScript, which is used forbuilding the prototype, presented in Chapter 5.

2.1. Collaborative Writing

In a globalized world, collaboration gains an increasing importance, with theInternet as its enabler. Especially Collaborative Writing has enormous benefitsfor working within groups. Different authors have always different viewpointswhich have to be discussed within the team. This also leads to a commonunderstanding and agreement about the written content10. The term Collabo-rative Writing itself has no generally admitted definition, but on the contrary,there are a lot of different words describing similar processes in research11.There is also no single clearly defined writing process, instead, there exist mul-tiple different ones. Therefore, there is a necessity of clarifying and definingthe term and the processes, so called strategies, more detailed for creating acommon understanding and nomenclature.

Collaborative writing involves multiple people and mostly describes the “pro-cess of writing as a group”12. This group must agree in advance to a common10cf. [Lo04, p. 67]11cf. [Lo04, p. 71]12cf. [Lo04, p. 70]

4

2. Foundations

strategy for the writing process. Section 2.1.1 introduces different writingstrategies and builds a taxonomy about the different ones.

2.1.1. A taxonomy for collaborative writing strategies

Collaborative writing can be done in a lot of different ways and is describeddifferently by researchers. These different ways refer to the “CollaborativeWriting strategy”. [Lo04] defined it out of former definitions as “a team’soverall approach for coordinating the writing of a collaborative document”.This section presents a taxonomy of different collaborative writing strategiesfor giving an overview of the existing ones as well as introducing the one whichis followed by this Thesis.

[Lo04] distinguishes between five major collaborative writing strategies thatare presented in Figure 2.1. Four of them are collected in two groups.

Figure 2.1.: Overview of Collaborative Writing Strategies

Single-author writing strategies are strategies where only one person is activelywriting at the same time. When using parallel writing strategies, the documentis divided into concrete units whereas each writer can work on such a unit inparallel. Reactive writing does not need any pre-planning and is done ad-hocin realtime. The concrete strategies are described in the subsequent sections.

5

2. Foundations

Figure 2.2.: Group Single Author Wri-ting14

Figure 2.3.: Sequential Writing15

2.1.1.1. Group Single Author Writing

The so-called “group single-author writing” is shown in Figure 2.2. Here, theteam chose one team member for doing the writing whereas the group discusseswhat shall be written. This is suitable for smaller groups and simple taskslike the processing of meeting minutes. As only one person writes the wholedocument, there is no conflicting styling. On the other hand, this method maynot results in the groups purpose and reflects more the intention of the singlewriter13.

2.1.1.2. Sequential Single Writing

The second strategy of single author writing, the “sequential-writing”, is morecommon. It is presented in Figure 2.3. Here, every author writes his ownpart and forwards it to the next author, for writing her task. An advantageof this method is, that the persons involved in the writing must not set upa meeting as they can complete the document iteratively, so, there is lessorganizational effort. At the same time, this can be a downside as there isno common agreement about the content as social interactions are lower thanwithin a meeting. The second disadvantage is, that subsequent writers caneasily overwrite the work which was done by the previous ones. Thirdly, onewriter has an enormous influence to the whole writing process, meaning, thathe can delay the completion of the document, whereas the last writer hasenormous control about the final version of the document. Despite of that,it is also difficult to divide the work correctly and to find the right order ofwriters16.

13cf. [Lo04, p. 81]15cf. [Lo04, p. 76]16cf. [Lo04, p. 76-77, 81]

6

2. Foundations

Figure 2.4.: Parallel Writing17Figure 2.5.: Horizontal-division Writing18

2.1.1.3. Parallel Writing

Another group of strategies of collaborative writing is the “parallel writing”which is shown in Figure 2.4.

Figure 2.6.: Stratified-division Writing19

It includes the “horizontal-division writing” and the “stra-tified-division writing”. Ateam, using these strategiesmust split the work into partswhich are processed by the dif-ferent persons of the group af-terwards. In contrast to thesequential writing, where thework is divided, too, the per-sons can work in parallel herewhich makes these methods

more efficient related to the produced content per time. The downsides ofthem are similar to the ones of the sequential writing, especially a poor socialinteraction. Additionally, different authors may do a different styling of theircontent and may produce redundant content. For using these strategies, spe-cial collaborative writing technology is needed20.The most used strategy of parallel writing is the “horizontal-division writing”which is shown within Figure 2.5. Here, each author produces a distinct part

18cf. [Lo04, p. 77]19cf. [Lo04, p. 79]20cf. [Lo04, p. 77-78, 81]

7

2. Foundations

of the document and all parts together build the final document afterwards.The other parallel writing strategy is the so called “stratified-division” wherenot all members of the group contribute content directly to the document, buttake a special role like “author” or “reviewer”, depending on their competences.This strategy is illustrated within Figure 2.6.

2.1.1.4. Reactive Writing

Figure 2.7.: ReactiveWriting21

The last form of collaborative writing is the “reactivewriting” which is shown in Figure 2.7. If this strategyis applied, every participant contributes in real-time.It is called “reactive”, because each author reacts tochanges and additions of the other authors. Thisform needs no planning or structuring in advance. Incontrast to the previously presented strategies, thismethod creates a common agreement about the con-tent. The main disadvantages are a complicated co-ordination and version controlling22.

2.1.2. Operational Transformation

Operational Transformation (OT) is a technology, helping to enable collabo-rative applications by offering a lot of different concepts in the field of col-laboration. First, OT was introduced in 1989 by C.A. Ellis and S.J. Gibbsin their paper “Concurrency Control in Groupware Systems”23. Followed by alot of research, some improvements and corrections in the subsequent years, itbecame a core technology for collaboration in industry, being used by a lot ofpopular collaboration tools like GoogleDocs, IBM OpenCoWeb, Novell Vibeor Codoxware24.

The basic idea of OT is illustrated in Figure 2.8 via a collaborative writingexample.

21cf. [Lo04, p. 80]22cf. [Lo04, p. 78-79, 81]23[EG89]24cf. [SWF12, p. 1391]25cf. [Su11]

8

2. Foundations

Figure 2.8.: Exemplary Scenario to show the basic OT Idea25

There are two persons shown, each one at a different location. For a betternomenclature, the person at site 1 is called P1 and the person at site 2 is calledP2. Both partners start with the same document which contains just the threeletters “abc”. Now, P1 and P2 start to edit or manipulate the document. Sucha document manipulation is represented by an operation. P1 adds the letter“x” at position 0 (operation O1) and P2 deletes the one letter “c” at position 2(operation O2). Within an OT system, local operations are executed as theyare and remote operations are transformed before their execution. This resultsat site 1 in an immediate execution of O1 and transformation of O2 and exactlythe other way around at site 2. The transformation of an operation is necessary,to reflect the impact of an operation, executed before. In the example at site1, O2 gets transformed to O2′ = Del[3, 1], to reflect the impact of O1, whichwas executed before. This concretely means an incrementation of the positionfor the deletion, as O1 added the character “x” before the original position ofO2. The execution of a remote operation without this transformation wouldresult in a falsely result. For example applying O2 at site 1 after O1 without atransformation would delete character “b” instead of “c” which would result in“xac”. At site 2, O1 gets transformed too, to O1′ but it is just the same as O1,as O2 has no impact on O1. After the execution of the own and transformed,

9

2. Foundations

remote operations on both sites, the document results in “xab” for P1 and P2,so, they have consistent documents.

There are two layers, which are responsible for these transformations. Theone is the transformation control algorithm, which decides, when an operationis ready for transformation, which operations should be transformed and inwhich order the transformations are carried out2627. The transformation itselfis done via a transformation function. This function takes two arguments, thetransformation target, which is the operation that will be transformed andthe transformation reference, which is the operation that influences the targetoperation. The output of this function is the transformed target operation. Adetailed description of the the transformation control algorithm or the trans-formation function including further references can be found in [Su11].

The above example was quite basic, and it wouldn’t work without the so calledoperation context. Each operation is executed and also only valid on a specificstate of the document, the operation context. Figure 2.9 shows a more complexexample to explain the concept of the context.

Figure 2.9.: Operational Transformation - Operation Context28

26cf. [Su11]27cf. [Su04, p. 438]28cf. [Su11]

10

2. Foundations

Both sites again start with the same document, therefore also with the samedocument state or operation context S0. The operations O1 and O2 both aregenerated out of this state, so, their context is S0. After applying O1 the stateof the document changes to S1 at site 1. At site 2, O2 changes the documentstate to S2 which is the context for the operation O3 generated afterwardsand so on. Every generated operation refers to a specific context, which canonly be changed by operational transformation.This context builds the foundation for a correct application respectively trans-formation of each operation and leads to two fundamental conditions for theconsistency maintenance of OT:

1. An operation On can only be correctly applied, if thesedefinition context is equal to the execution contextThe original context of an operation is the so called “definition context”,the context, where the operation is applied, is called “execution context”.An operation On can only be correctly applied, if these two contexts areequal. The definition context of O1 in the example shown in Figure 2.9is S0, which is the correct execution context at site 1 too. When O1

arrives at site 2, the execution context is S4, so if it would be applied,the resulting state would be “a1x234bc”, which is not correct as the rule,mentioned above was not obeyed as S0 6= S4. Instead, O1 must betransformed as shown in Figure 2.9 to O1′ = Ins[6, ”x”], which can beapplied now correctly on S4 and results in the same result as O1 wouldproduce in S0.

2. Two operations can only be transformed if they are defined inthe same document stateIn Figure 2.9, O1 and O2 are generated out of the same document stateS0, so they can be transformed with each other correctly as they referto the same positions within the text, which is necessary for a correctapplication. A contrary example are the operations O1 and O3, whichdoes not have the same context (S0 and S2), and therefore cannot betransformed with each other directly. Instead, O1 must be first trans-formed with O2 resulting in O1′, which has the context S2, just the sameas O3, therefore, they can be correctly transformed now.

Despite of consistency maintenance of shared documents between multiple con-current editors, OT provides more capabilities like an undo-functionality, a

11

2. Foundations

“workspace awareness” in 2D and 3D workspaces, a locking functionality oroperation notification mechanisms29.

2.2. Transport Technologies

This section presents technologies for enabling realtime communication be-tween client(s) and a server. From the beginning of the Hypertext TransferProtocol (HTTP) until the time of writing this Thesis, there was a lot of devel-opment in this field. Figure 2.10 presents the milestones of this developmentin form of a timeline. For sure, these milestones influenced each other. Allof them are based on the Transmission Control Protocol (TCP), that ensuresa reliable connection between two computers. The development of Ajax andComet for example was only possible through the development of HTTP 1.1.

1991 20111999 20071995 2003

HTTP 0.91991

HTTP 1.01996

HTTP 1.12000

Ajax 2005

Comet2006

WebSockets2009

WebRTC2011

Figure 2.10.: Important Developments for realtime Web Applications

In the past, the Internet was mostly website-centric (see Chapter 1), whichwas also the reason for HTTP being designed as a “protocol for retrievingdocuments”30. This design decision led to two fundamental characteristics forits first specification 1.0 (version 0.9 can be seen as a prototype version ofHTTP31). As a website visitor is interested in a specific document, she sendsa request to the server, therefore, the communication is always started by theclient and not by the server. For just delivering documents, the server does notneed to know any meta information about the user, requesting the document,therefore the second important characteristic was, that the server does not save

29cf. [Su11]30cf. [MC08, p. 2]31cf. [GT02, p. 16]

12

2. Foundations

any state about its clients32. A typical communication process with HTTP canbe seen in Figure 2.11.

Figure 2.11.: HTTP Communication process33

The client sends a request to the server which then sends the respectiveresponse without saving any information. So, the communication is client-initiated and stateless34.

As the web changed from a document-centric to a user-centric model (seeChapter 1), this paradigm was not fitting any more. There was a need forcommunications being initiated from the server and not only from the client35.An important improvement for further developments were the “Persistent Con-nections” of HTTP’s specification 1.1, which is the current version of HTTP36.This connection type allows, to keep the underlying TCP/IP connection openafter an HTTP transaction is completed, for a reuse of this connection37. Thispaved the way for Ajax, which came out in 2005. Ajax was mostly coined byJesse James Garrett who described in an article a way, to send requests to awebserver in the background, without a full refresh of the opened webpage38.This was a very important step for enabling a lot of new experiences withinthe web. Now, it was possible to create dynamic webpages with immediate

32cf. [MC08, p. 2]33cf. [MC08, p. 3]34cf. [Th99, p. 4]35cf. [MC08, p. 3]36cf. [GT02, p. 16]37cf. [GT02, p. 91]38cf. [MC08, p. 1-2]

13

2. Foundations

user response, like feedback messages or content, which is loaded on demand,or an automatic appearance or removal of whole parts of the website39. Al-though Ajax made big improvements for a realtime user experience within theweb, it still followed the pull interaction model which means, that the browserpulls the content from the server, so, the communication between them is stillinitiated by the client 40. This model is not sufficient for realtime scenarios,for example a progress bar, where you see the current percentage of alreadyuploaded megabytes of an image, which is sent to an online web album. Aneven more important example would be a monitoring tool, which sends alerts ifa specific temperature is reached and an immediate reaction is needed. Withinthese scenarios, the server has new information, which must be propagated tothe client(s) and here sometimes it is not fast enough, to wait for the nextrequest done by the client. Therefore more advanced techniques are needed,where the server initiates a connection to a client to send new information atany time.

Within this chapter, some of these techniques required for realtime scenariosare described. Figure 2.10 illustrates a timeline with all the presented tech-nologies and their year of appearance.

2.2.1. Polling and Piggibacking

The most simple method to introduce a realtime user experience is the so calledpolling. Polling means, that the client sends requests to the server regularly inthe background by using Ajax mechanisms, looking if there is new informationavailable. The rough sequence is shown in Figure 2.12.

The first poll or request offers no new information for the client, therefore,there is just a normal response from the server. Within the second poll, theserver has new information which are sent via the response. For instance, inchat application, which allows users to send messages to each other, this couldbe one message.As it can be seen in Figure 2.12, the period between two polls is a tradeoffbetween actuality or technically spoken response-time and communication andresource effort. Keeping the time between two polls short means, that updates

39cf. [Po07, p. 1]40cf. [Ro10, p. 4]

14

2. Foundations

Figure 2.12.: Polling Process

like a new chat message arrive earlier at the client which leads to a better re-altime experience. The disadvantage of this approach is that a lot of messagesmust be sent which leads to a higher load for both, the client and a server andalso for the underlying network. In the example of figure 2.12, most of theexchanged messages are not needed, as there is no new information available.If, for example, the server is connected to a sensor which always has new infor-mation after a specific timeframe, this approach fits good as this timeframe canbe synchronized with the clients interval for sending requests to the server.

Another simple approach is the so called “Piggybacking”, which makes use ofa user initiated action like update, delete or create. Usually, the response tosuch actions is just sort of an acknowledgement of receipt. When using Pig-gybacking, such responses are enriched with update information, also to othermodels not related to the currently requested one.This method can also optimize polling. If a normal answer to a user request,not belonging to the poll message flow, is enriched with further data via pig-gybacking, the time to wait until the next poll is reseted. Therefore, Piggy-

15

2. Foundations

backing can decrease the number of polls and make the whole communicationmore efficient41.

2.2.2. Comet

Section 2.2.1 showed, that the simple approaches to enable realtime commu-nication in web applications are still based on communications, initiated bythe client. This often does not meet the requirements for realtime scenariosin terms of latency. There might be a high delay between the occurrence ofa new event and the time of realization at the client. This is, what Comet isaddressing. The goals of Comet are enabling the server, to send data to theclients at any time, more efficient related to speed and scalability, than theAjax based approaches described above. The term itself describes techniques,protocols and implementations to achieve these goals and is mainly coined byAlex Russel, the creator of the DoJo framework42.In contrast to the typical HTTP communication process shown in figure 2.11,where the client initiates the communication, figure 2.13 shows a comet com-munication process.

Figure 2.13.: Comet Communication Process43

This approach has no step, during which the client asks for updates. If theserver holds new information for one or more clients, it just sends them to therespective recipients. The following sections describe different Comet tech-nologies.

41cf. [MC08, p. 19-31]42cf. [SA09, p. 109]43cf. [MC08, p. 3]

16

2. Foundations

2.2.2.1. Long Polling

Long Polling is a method, which fits to the goal of Comet, that the servercan send new data to the browser at any time, although it doesn’t fit directlyto the comet communication process shown in figure 2.13. To enable LongPolling, the client or respectively its browser, sends a request to the server.Instead of responding directly with a concrete message which would end theconnection just like it is the case with polling (see section 2.2.1), the serverholds the connection open by responding either “Transfer-Encoding: chunked”or “Connection: close”. With this approach, the client waits for messages fromthe server, who can send the new data to the respective client, directly after itis available at any time. If the client received these new data, the connection isclosed. For enabling this functionality over the whole time, the user visits thewebpage, the browser opens a new connection to the server directly afterwards,so the server is again able to send new data when there is something available.This reconnection method is also used, if the connection is disrupted somehow.As mentioned above, the connection itself is still initiated by the client, butthe server can send updates, directly when they occur. It also removes theunnecessary regular requests, compared to the polling method, which reducesthe load for the client, the server and the underlying network.This approach enables a realtime user experience but results in new require-ments for the server. Especially traditional webservers are optimized for afast opening and closing of connections, to handle incoming requests as fastas possible. Now, there is a huge number of parallel long-lived connections,which must be kept open. The Apache webserver for example, is optimized tohandle about ten thousand parallel connections, but, for being able to realizea cost-efficient realtime enabling server-side, this one should be able to handleabout fifty thousand long-lived connections, which is one requirement for agood Comet server44.

2.2.2.2. Forever Frame

The first technique for realizing Comet was the forever frame, which relieson chunked-encoding, which is defined in HTTP 1.1’s specification. Chunked-encoding divides the HTTP message body into different messages, so called

44cf. [SA09, p. 112-113]

17

2. Foundations

chunks, which are sent independently. This can be used to transfer dynami-cally produced content45 or large documents incrementally. In the context ofComet, a usually hidden iFrame refers to a chunked-encoded document, wherethe server can put in the new data, when necessary. Figure 2.1 shows suchexemplary messages.

Listing 2.1: Example messages from the server46

1 <script>2 parent.foreverFrame.callback("the first message");3 </script>4 <script>5 parent.foreverFrame.callback("the second message");6 </script>

Both are invoking a function on the client-side, with the message as parameter.The message itself can be for example “You have new messages in you inbox”and the method, which is invoked might display this message in an alert box.To avoid, that this iFrame becomes too large, the client must do sort of agarbage collection, e.g. remove DOM-nodes out if the iFrame, when they arenot needed anymore like a script tag within figure 2.1 which is already fullyprocessed.47.

2.2.2.3. XHR Streaming

The XMLHttpRequest (XHR) is the common transport mechanism for pollingand long polling and builds the foundation for all Ajax approaches. XML-HttpRequest itself was first developed by Microsoft as an ActiveX object, firstcalled Microsoft.XMLHTTP, but the idea was shortly thereafter adopted byMozilla, who developed an alternative called XMLHttpRequest. The XHR al-lows, to send requests to a server within the webpage fully in the backgroundwithout the necessity of reloading the whole page or locking the page whilewaiting for the response48.Today, most of the current browsers like Firefox, Chrome, Safari and InternetExplorer 8 support the XHR, which can be used, to not just make requests inthe background like Ajax but also to stream data from the server to a client at45cf. [Th99, p. 24-26]46cf. [SA09, p. 114]47cf. [SA09, p. 113-115]48cf. [Po07, p. 4]

18

2. Foundations

any time without the necessity of a new HTPP connection for each new infor-mation. The streaming functionality can be realized via utilizing the differentso called ready states of XHR, which are shown in Table 2.1.

Ready State NumericValue

Description

UNSET 0 The XMLHttpRequest object has been createdOPENED 1 The open method has been successfully in-

voked, which means among other things, that avalid HTTP method and a valid and resolvableurl was set. Within this state, other HTTP re-quest headers can be set and the request canbe initiated, by invoking the send method

HEADERS_RECEIVED

2 All redirects have been followed, if there wereany and all HTTP response headers have beenreceived. Some parts of the response are avail-able now.

LOADING 3 The entity body of the response is being re-ceived

DONE 4 The whole data is completely transferred to theclient or an error occurred during the transfer

Table 2.1.: Ready States of the XMLHttpRequest Object49

Within state 3, the client can access data, which is received before the wholeresponse is sent and the HTTP connection is closed, which would be indicatedby ready state 4. So, with using especially state 3, the server can send data atany time to the client, only within one HTTP connection. The downside of thisapproach for the server is almost the same as it is with long polling, but thereare new difficulties for the client. As the client stores all data received, if toomany messages are sent over one single HTTP connection, the browser on theclient-side can get into memory issues. To avoid this, it is not recommendableto use just one single HTTP connection for all messages, but to close thecurrent and open another one after a certain number of messages received fromthe server, just as long-polling is doing it for every message. Another difficultyfor the client is, to get the complete messages out of the stream, which must berealized with a parser. For an easy utilization of XHR streaming, the client cantake advantage out of the onreadystatechanged -events, which are fired always,if the ready state changed50.

49cf. [W3]50cf. [SA09, p. 115-116]

19

2. Foundations

2.2.2.4. JSONP Polling

Sometimes it is important, to send requests to another server (on another do-main) as the webpage was delivered from. For example it can be the case,that the website and other static content is just delivered by a normal HTTPserver, and the realtime functionality is realized via a different comet serveron a different domain. Another typical use case is the usage of third partyservices. Accessing a different domain than the website was delivered fromrefers to the cross-domain problem.Polling, long-polling and XHR streaming are typically built on top of theXMLHttpRequest, therefore, the cross-domain ability of these methods highlydepends on the cross-domain ability of the XHR, which normally doesn’t al-low cross-domain access. When using the forever frame method, and withsome workarounds also with the XHR streaming, at least a cross-subdomainaccess can be realized, but still, this is no cross-domain. The technique whichrefers to this requirement is called JSONP polling. JSONP polling relies onthe simple polling approach described in section 2.2.1, but instead of using theXMLHttpRequest object, it makes use of <script>-tags, which are appendedto the document for each new request. If such a tag appears within the docu-ment, the browser loads and parses it. With JSONP, the response of loadingthis script is surrounded by a function, which can be called and returns thethe loaded data. The script tags are normally used for loading scripts fromany server. With JSONP polling, this characteristic can be utilized to makingcross-domain requests51 52.

2.2.3. Flashsockets

Flash is a technology of Adobe Systems Incorporated, for producing anima-tions, multimedia and interactive content for different devices53. For mak-ing Flash runnable on a client, a special software must be installed calledFlashPlayer. Flash can be used alone but in combination with ActionScript,a programming language developed especially for Flash, running within theFlashPlayer on the client, more complex scenarios can be implemented likedrawing programmatically, loading data or respond to user events.

51cf. [MC08, p. 40]52cf. [SA09, p. 116-118]53cf. [Ad12]

20

2. Foundations

One advanced functionality, which Flash brings in combination with Action-Script are sockets that allow a bidirectional communication between the clientand the server. Nevertheless, this technology is proprietary and the respec-tive FlashPlayer must be installed on every machine, that want to use thiscommunication mechanism54.

2.2.4. HTML5 Websockets

“HTML is the publishing language of the World Wide Web.”55 The first ver-sion of HTML was developed in 1993, followed by three versions in the sameyear while the next to last version (4.01) was developed in 1999. In 2004, whenthe term “Web 2.0” became popular, a small group of people founded the “WebHypertext Application Working Group” to develop a new HTML standard forenabling more powerful web applications. Despite of a lot of new features andAPIs like Canvas, scalable vector graphics, audio and video or geolocation, oneAPI was integrated in the new HTML5 specification which is quite importantfor enabling realtime communication in web applications, the HTML5 Web-Socket API. HTML5 follows a plugin-free paradigm, meaning, that all featuresmust be usable natively and without any plugin as it is the case for example,when using flash (see 2.2.3).WebSockets realize a full-duplex connection, meaning the client, which is nor-mally a web application and the websocket-server can send data at the sametime to each other. WebSockets are lower-level networking interfaces that pro-vide a bidirectional stream which arrive in the same order as it was sent justlike TCP. In contrast to TCP, WebSockets connect to URIs instead of hostsand ports.

An example about how WebSockets can be used is shown in Listing 2.2.

Listing 2.2: An usage example for WebSockets56

1 var myWs = new WebSocket("ws://www.websockets.org");2 myWs.onopen = function(evt) { alert("Connection open ..."); };3 myWs.onmessage = function(evt) { alert( "Received Message: " + evt.data); };4 myWs.onclose = function(evt) { alert("Connection closed.");5 myWs.send("Hello WebSockets!");6 myWs.close();

54cf. [Br10, p. 3, 561-570]55cf. [W312]

21

2. Foundations

WebSockets can be opened at the client side via JavaScript. In line one, theWebSocket is created and the communication is built to the given URI. Fromline two to line four, the evented nature of WebSockets can be seen quite good.They all add a listener to a special event(“open”, “message”, “close”), where eachtime the listener is a function which is called, when the respective event is fired.To send a message just the “send” method has to be invoked as it can be seenin line five. The last line within the listing closes the connection.

Listing 2.2 showed an easy example of a client-server communication-process.It can be seen, that one of the other goals of HTML5, the “Simplification” wasachieved for the WebSocket API. Doing such an easy communication examplewould have taken much more lines of code in the Comet approaches, describedin Section 2.2.2.Despite of the easiness of use, WebSockets have some other advantages overthe previously introduced approaches. First, the connection is only built oncein contrast to polling, which needs for each request a new connection or alsolong-polling or XHR streaming, which must build a new connection after a cer-tain number of messages, therefore, there are a lot less connection handshakesneeded. Furthermore, WebSockets offer a better latency behavior, which canbe best seen compared to polling. Assume, the server wants to send some datato the client with a latency between the client and the server of 50ms as it isshown in Figure 2.14.

The upper timeline shows the communication process realized with polling.This is a half-duplex connection, therefore, the client must send a request foreach new data, which makes the whole communication slower because of thelatency, compared to the WebSocket approach. The client sends a request,which takes 50ms. Assume the server sends his data directly, after the requesthas received, which takes another 50ms until the data arrive at the client andhe can send another request. So, we have a round-trip time of 100ms untilthe client sends another request. With WebSockets, we have a full-duplexconnection. The server can send new data at any time. There is still thelatency of 50ms, but as there is no request needed, the WebSocket round-triponly takes 50ms for one single message58. At last, the communication doesn’twork on top of HTTP which leads to a reduced amount of data which has to

56cf. [Ka13]57cf. [PL11, p. 169]58cf. [PL11, p. 1, 5, 6, 161-169]

22

2. Foundations

Figure 2.14.: WebSockets vs. Polling57

go through the network, as the unneeded HTTP-header information are notsent with messages over WebSockets.

2.2.5. Summary

In this chapter, the technical foundations for enabling realtime communicationfor web applications were introduced. It became apparent, that the first sim-ple approaches shown in Section 2.2.1 were at least a step in right direction,but neither efficient nor enabling a good realtime user experience. The en-hancements with long-polling, forever-frame or XHR streaming increased theefficiency and reactivity of web applications but there are still downsides e.g.the garbage collection, meaning, that the client has to take care of its mem-ory usage. With JSONP-polling, a viable solution for cross domain Ajax wasintroduced, which has still the disadvantages mentioned just now.Socket connections provide a better alternative for enabling realtime com-munication. They realize full-duplex connections and compared to the othermethods the best realtime user experience. Flash sockets depend on the in-stallation of the Flash Player plugin, which has some disadvantages howeverits distribution is quite high. HTML5 WebSockets are the newest developmentin this field. They have a lot of advantages over the other introduced methods

23

2. Foundations

and run natively, without any plugin. The downside here is, that they are notavailable for all browsers currently.

2.3. Realtime Web Applications - A Market

Analysis

This section gives an overview about currently available web-based collabora-tion tools. First, each tool is presented briefly whereas Section 2.3.6 comparestheir features and gives a summary.

2.3.1. Google Docs

Google Docs is part of Google Apps which is a “productivity suit” of GoogleInc. It is realized by cloud-based web applications that enable users to accesstheir data computer independently via a internet browser. Whereas GoogleApps focuses on business and educational customers, there are a couple ofapplications also available for personal use, which applies for Google Docs,too.Google Docs is a text-processing web application whereas Figure 2.15 showsan exemplary document created and edited with Google Docs.

Figure 2.15.: Screenshot of Google Docs

24

2. Foundations

Despite of rich-text-editing it offers functionalities like the embedding of tables,images or mathematical equations. Furthermore, it enables Google users towork collaboratively on the same document59. There are two people editing thedocument concurrently within the figure. The purple color marks the positionof the cursor of the second user. Google Docs also provides a revision historywhich enables the user to restore different version of the document. Such aversion is created regular automatically.

2.3.2. Etherpad (lite)

Etherpad lite is an “Open Source online editor providing collaborative edit-ing in really real-time”60. It is the advancement of Etherpad and was fullyre-written in Node.js61. Figure 2.16 shows an exemplary document withinEtherpad lite.

Figure 2.16.: Screenshot of Etherpad lite

Again, there are two authors editing concurrently within the document. Ether-pad does not show cursor positions, instead, the text of each user is highlighted

59cf. [Go13]60[Th13]61cf. [Th13]

25

2. Foundations

with a unique color for each user. It provides basic text formatting capabil-ities like making it bold, italic, underlined or strikes trough. For reviewingpurposes, it provides a so called “Time Slider” which enables the user to gothrough all versions. Each time a user does a change on the document such aversion is created.

2.3.3. ShowDocument

ShowDocument is a “Web Meeting and Document Sharing” web application. Itoffers various apps for working collaboratively like a shared online whiteboard,voice, video and text chat functionalities, screen-sharing capabilities and acollaborative editor for documents62. The last mentioned app is shown inFigure 2.17.

Figure 2.17.: Screenshot of ShowDocument

Again, there are two users editing the document. There is neither a cursor ofthe users visible nor is there a highlighting to mark which text was edited bywhom. In contrast to the other tools, it provides a mouse-cursor synchroniza-tion. The text formatting includes the usage of different fonts and colors orthe styling as bold, italic oder underlined.

62cf. [HB11]

26

2. Foundations

2.3.4. Zoho

Zoho offers a lot of web applications for collaboration, business and produc-tivity. Collaboration applications are for example are the chat-, meeting-,projects-, wiki-, mail or docs-app whereas we are interested in the last one. Itenables their user to create and work collaboratively on document,s spread-sheets and presentations63. The respective word processor is shown in Figure2.18.

Figure 2.18.: Screenshot of Zoho

Within the figure, two users are editing the document collaboratively. As it canbe seen, the cursors are marked with different colors. Zoho’s word processoroffer a variety of different text formatting capabilities and elements that can beintegrated into the document like images, tables or mathematical equations.

2.3.5. Web IDEs

In the field of collaboration tools, there are a lot of collaborative IDEs. Theyfocus on the development of source code for different programming languagesand therefore enable mechanisms for a collaborative creation of source code.

63cf. [Zo13]

27

2. Foundations

Examples are ShareLaTeX64, Squad65 or cloud966. An example can be seenwithin Figure 2.19 which shows the cloud9 IDE.

Figure 2.19.: Screenshot of cloud9 IDE

The all have in common, that they support collaborative editing, but do notsupport any rich text content or the embedding of tables or images which isclear for source code. They actually do support syntax highlighting for vari-ous programming languages and event further mechanisms like an automaticdeployment of the code.

2.3.6. Feature Comparison and Summary

This section summarises the key findings about the above presented web col-laboration tools. Table 2.2 shows metrics and how well they are supported bythe respective tools. The Web IDEs are kept out of this comparison, becauseof their special focus on source code.

64[Sh13]65[Co13]66[Cl12]

28

2. Foundations

GoogleDocs

Etherpadlite

Show-Documents

Zoho

basic text formattingadvanced elements (ta-bles, images)cursors visibleversioning

Table 2.2.: Summary about the collaboration tools and their features

Etherpad lite offers the least basic text formatting capabilities which are stylingthe text bold, italic, underlined our striked through. Furthermore, a colourand text indention can be set. ShowDocuments enhances this a bit by pro-viding multiple fonts.Google Docs and Zoho in contrast provide a rich paletteof text formatting capabilities. Additionally, they enable the integration oftables, links, images. Zoho is even able to automatically generate table of con-tents. ShowDocuments is the only tool, that does not display a cursor at all.Google Docs and Zoho show a coloured cursor of each user, whereas Etherpadhighlights the text of each one.The last criteria is the versioning. ShowDocuments does nod provide any ver-sioning whereas Zoho offers the manually creation of different ones. Google-Docs creates automatically versions in a regular basis. Etherpad lite has themost accurate versioning system. Each change, that is done within the docu-ment automatically creates a new version of it.

2.4. Node.js

Node.js is a JavaScript interpreter. It was developed by Ryan Dahl and firstpresented at JSConf EU in November 200967. The most important thing aboutit is, that it offers a way of running JavaScript code outside of the browser. Todo so it extends Google’s JavaScript interpreter V8 with bindings to low-levelAPIs. This enables for example the working with processes, access to files or

67[Da11]

29

2. Foundations

the usage of network sockets with JavaScript.

Almost every binding of Node.js is asynchronous therefore Node.js never blocks.It is based on event handlers and follows an event-driven approach, just asJavaScript itself which leads to a good scalability and an effective handling ofhigh loads68. In contrast to traditional programming, where the program doesfor example a database query and blocks until the answer is provided, Node.jsregisters a callback function that is invoked, when the database result is ready.In the meantime, Node.js can do other things. This behavior is realized withan event loop which does two functions in a continuous loop: the detection ofevents and the triggering of event handlers. This event loops runs in one threadwithin one process which results in the situation, that alway one event handlercan run at the same time. Furthermore, this handler is not interrupted, it runsuntil it’s completion69. A consequence of this is, that there synchronizationbetween parallel executed code needed as this simply never happens.

Meanwhile, Node.js is sponsored by Joyent, a company specialized on cloudcomputing and realtime web applications70. Furthermore it gained acceptancein industry as it is used by companies like eBay71, LinkedIn72 or Yahoo73.

2.5. Tricia

Tricia is an open-source Java platform developed by the chair for SoftwareEngineering for Business Information Systems of the Technical University ofMunich and commercialized by the infoAsset AG74. It is used for implementingenterprise web information systems and social software solutions like wikis,blogs, file shares and social networks75. Furthermore it offers hybrid wikifunctionalities that extend Tricia’s wiki component. Hybrid wikis enrich classic

68cf. [Fl11, p. 296]69cf. [Te12, p. 16-17]70cf. [Jo13a]71cf. [EB11]72cf. [Ch12]73cf. [FR11]74cf. [in12]75cf. [BMN10, p. 1]

30

2. Foundations

wiki software with a subset of semantic wiki features that allow to combinethe textual content of a classic wiki with structured data76.Data Model Driven Implementation of Web Cooperation Systems with Tricia 3

Fig. 1. Architectural overview of a typical web application implemented on the Triciaplatform

A Tricia application consists of a core and one or more plugins that definethe application in a modular fashion (see shaded areas in Figure 1). Each pluginspecifies the plugins it depends on. Cyclic plugin dependencies are not allowedand are detected at construction time. For example, the plugin Wiki depends onthe plugin File, since files may be attached to wiki pages and wiki managementthus requires file management.

The core defines abstractions required by virtually all applications of thedomain, for example user profiles, groups, memberships, login and registrationprocedures. The plugins Wiki and File both use such user profiles to identifythe last editor of a wiki or a file. Other abstractions provided by the core arediscussed in Section 4.4.

Each plugin and the core define a data model, an access control model andan interaction model. Each model defines a fragment of the data structures andbehavior of the entire application. These models are expressed by graphical andtextual notations (see Section 4) and are available at runtime for introspec-tion (ovals in Figure 1). If necessary, they can be augmented by customizationswritten in Java (e.g., to express business logic). Models from a plugin P may ref-erence models in P and in plugins imported by P (depicted by arrows in Figure1). The following rules apply: Interaction models may reference other interac-tion models, access control models or data models. Access control models mayreference other access control models or data models. Data models may refer-

Figure 2.20.: Architecture of a typical Web Application implemented in Tri-cia77

A typical web application implemented on the Tricia platform can be seen inFigure 2.20. It consists of the so called core and plugins. The core is providedby the Tricia development team and offers functionalities which are neededby a majority of applications for example user profiles, groups, memberships,login or registration mechanisms. It is layered in frameworks for data model-ing, access control and user interaction whereas each framework has its ownunderlying model. The plugins, used in the example in Figure 2.20 are “File”and “Wiki”, whereas the “Wiki” plugin depends on the “File” plugin.

76cf. [MNS11, p. 1-2]77cf. [BMN10, p. 3]

31

2. Foundations

There are multiple ways to interact with Tricia as a user, realized by differentinterfaces. There is the possibility to use it via the web browser over HTTP(S),within a desktop application over SMB or WebDAV78.

78cf. [in12]

32

3. On the Role of Server SideJavaScript in Organisations

JavaScript has an increasing popularity, as evidenced by being by far themost popular language at GitHub79 and its usage for the majority of mod-ern websites80. Additionally [O’12] did a survey, which analyses the GitHuband StackOverflow programming language popularity. JavaScript was rankedthere at the first position, just before Java and PHP. Given the importanceof JavaScript for Web development, especially at the client-side, there is alsoan emerging trend for using JavaScript for the full web stack, as new develop-ments like Node.js or NoSQL-databases are showing. However, there is onlylittle known about JavaScript’s use and reputation in organizations, for both,the client- and the server-side.This survey, conducted within the scope of this Thesis, tries to fill this gap.

3.1. Survey Related Work

There has been several studies conducted comparing dynamic type systems tostatic type systems. Parts of them directly relate to this survey, as JavaScriptis a dynamically typed language.[PT98] performed an experiment, where experienced programmers solved shortprogramming tasks in both, a type-checking and a non-type-checking language.They figured out, that using type checking of interfaces, leads in a lot of casesto improved productivity and software quality and can result in a decreasingneed of resources while the development. Also [Ga77] identified a positiveinfluence of static type systems on development time. [SH11] refers to twounpublished works that showed, that a static type system leads to a fasterusage of undocumented APIs. Furthermore, the identification and fixing of

79cf. [Gi13]80cf. [Fl11, p. 1]

33

3. On the Role of Server Side JavaScript in Organisations

type errors within a software is easier. This finding is supported by [Kl12],who showed within an experiment, that a static type system decreases de-velopment time of programming tasks requiring fixing type errors. However,[SH11] mentioned, that there is no difference for semantic errors, compared todynamically typed languages.

[Ha10b] conducted an experiment where 49 subjects were divided in two groupsand had to program a simple Java parser, whereas one group used a staticallyand one used a dynamically typed language. In contrast to the findings above,this experiment showed, that statically typed languages do not have an obviousbenefit over dynamically typed languages under all circumstances. [SH11] evenshowed within an experiment, that dynamically typed languages positively in-fluences development time. This finding is supported by [Ha10a]. He did anexperiment, where development time and the quality of the programmed codewas measured for two groups. Both developed the same piece of software butone group used a statically typed language, whereas the other group used adynamically typed one. It turned out, that there was no significant differencebetween these groups related to the resulting code quality but the develop-ment time, was significantly lower for the group, using the dynamically typedlanguages. It is noticeable, that newer publications tend to upgrade dynamictyped languages in contrast to older publications, that evaluate static typinghaving a positive impact on software development.

Sun Labs used JavaScript as a “Real Programming Language” for developing aweb programming environment with approximately ten thousand lines of code.In [MT07], they expressed their experiences for using JavaScript as a generalpurpose programming language. In summary, their result was, that JavaScriptis a powerful and expressive language, suitable for developing real applicationsand even system-software. They suggest an incremental and evolutionary de-velopment approach for the effective use of JavaScript, which is more familiarto developers grown-up with dynamically typed languages, than those, whoare more used to programming languages with a static type system. They alsoclaimed, that JavaScript’s permissiveness and error tolerance has a negativeimpact on application development and debugging.

34


3.2. Survey Design

Given the limited literature and research about the assessment of client- andserver side JavaScript in organizations, an exploratory survey across multipleenterprises and industries has been performed. The aim is, to gain an overviewabout organization’s use and assessment about JavaScript, Node.js and theirfuture. In order to evaluate our own experiences and statements found in lit-erature, we formulated five research hypotheses to evaluate these observations.

[Kl12] identified within a survey, that the time, needed to fix type errors withina software, is decreased when using a programming language with a dynamictype system. In addition they mentioned an often upcoming statement thattool support for statically typed languages is easier achievable. This led us tothe first Hypothesis:

Hypothesis 1 JavaScript developers are not satisfied with the current tool sup-port

When using JavaScript as a general purpose programming-language, [MT07]identified different syntactical issues like redundancy or accidental syntax er-rors, which has major consequences especially because of JavaScript’s errortolerance. Another indicator for syntactical problems of JavaScript might bethe current development of languages like CoffeeScript, that try to “exposethe good parts of JavaScript in a simple way”81 and introduce a new languagewhich compiles to JavaScript. The study of [O’12] even listed CoffeeScript asthe 19th popular language. Therefore, we formulated the second hypothesis.

Hypothesis 2 Developers do not like the syntax of JavaScript

The maintainability of software refers to the simplicity for modifying it. Animportant aspect of maintainability is the analyzability, which refers amongothers to the locating of errors. As different researchers describe (see Section3.1), this is problematic especially for dynamically typed languages. Also thedevelopment environment is an important factor for maintainability82. Thetool support greatly contributes to this, which is not optimal for dynamiclanguages as described above, which led us to the next hypothesis:

81cf. [Fi12]82cf. [Sp06, p. 325, 451]

35


Hypothesis 3 JavaScript code is hard to maintain

As described in the introduction, JavaScript has a quite high popularity at themoment, shown by different studies and by the fact, that JavaScript is used forthe majority of modern websites. As we expect, that this trend will continue,we claim the fourth hypothesis:

Hypothesis 4 The general importance JavaScript will rise in future

Node.js currently attracts a lot attention. Big companies like eBay83, LinkedIn84

or Yahoo85 build tools with it. Microsoft writes a special language for “app-lication-scale JavaScript” with Node.js support86 and enriches its web devel-opment tool Webmatrix2 with enhanced Node.js functionality87. Additionally,Microsoft supports Node applications on their platform-as-a-service productWindows Azure88. This wide industry support made us stating the last hy-pothesis.

Hypothesis 5 Node.js is suitable for enterprise applications

To evaluate our hypotheses and to gain a broader knowledge of organizationsview on JavaScript and Node.js, we compiled an online questionnaire. It wasdivided into three sections. The first asking questions about JavaScript, thesecond focusing on Node.js and the third for getting knowledge about the par-ticipant and its company. Additionally, we provided a few open text fields ineach of these sections to collect general moods about these technologies. Afterdesigning the questionnaire, a pretest was conducted with two researchers andfour employees of the PENTASYS AG, who were not involved in the prepara-tion. The suggestions and feedback, which were produced within the pretestwere included in the questionnaire and the final version was published as anonline survey, available for 21 days. We have send invitations for participatingin the survey to over 1000 industry partners of the chair for Software Engi-neering for Business Information Systems of the Technical University of Mu-nich. Additionally, the survey invitation was published on Xing, LinkedIn, theNode.js mailing list, a Google+ circle with 242 people included, mostly inter-ested in JavaScript and the web forums jswelt.de, webdeveloper.com, python-

83cf. [EB11]84cf. [Ch12]85cf. [FR11]86cf. [Mi12]87cf. [Mi13a]88cf. [Mi13b]

36


forum.com and ruby-portal.de.We received 123 answers in total, whereat 23 participants (∼19%) have notcompleted the full questionnaire and were excluded from the evaluation. 37%of the participants were working in Germany, 22% in the USA, 5% in theUnited Kingdom , 3% in Italy and Austria and 2% in Australia. 10% did notgave the country, where they are working from currently. Each of the rest ofthe participants (21%) was working in separate countries all over the world.Table 3.1 illustrates the distribution of industry sectors of the participants.

Industry Sector n % of allIT Products and Services 32 32%IT Consulting 13 13%Telecommunications 6 6%Finance 5 5%Education 4 4%Production and Manufacturing 3 3%Automotive 2 2%Transport / Logistics 2 2%Games 2 2%Measurement Devices 2 2%Health 1 1%Management Consulting 1 1%Public Service 1 1%Open Source 1 1%Other 10 10%

Table 3.1.: Survey Design - Organizations by industry sector

IT Products and Services was the largest sector with 32%, followed by ITConsulting with 13% and Telecommunication with 6%. Within the “Other”there was, despite of others, IT security, e-commerce and science mentioned.Table 3.2 shows the distribution of job titles of the participants.

The majority of participants were Software Engineers, with an amount of 47%.The second largest group of job titles was built by IT Architects with 10%, fol-lowed by Enterprise Architects with 7%. Within the “Other”, there was despiteof others a Head of Application Security, a Head of Research & Developmentand a trainee. The Consultants, with an amount of 3% were advised to answerthe questions related to a single, concrete project, they have worked in.In addition, we asked the participants for the typical kind of projects within

37


Job Title n % of allSoftware Engineer 47 47%IT Architect 10 10%Enterprise Architect 7 7%CXO 5 5%Project Manager 4 4%IT Operations 3 3%Consultant 3 3%Business Architect 1 1%Other 8 8%

Table 3.2.: Survey Design - Participants by job title

their organization, whereat multiple answers were allowed. The given answersare shown in Table 3.3.

Kind of project n % of allWeb Development 79 79%Cloud Computing 35 35%Desktop Applications 26 26%Embedded 13 13%Security Applications 10 10%Mobile Applications 4 4%Other 3 3%

Table 3.3.: Survey Design - Typical kind of projects within the organizations

The majority of projects were within the field of Web Development with anamount of 79%. 35% of the projects were related to Cloud Computing, followedby the group of Desktop Applications with 26%. 13% of the organizationstypically had embedded projects and 10% build Security Applications. Thesmallest group of projects with 4% was related to Mobile Applications. 3%of the projects had another focus, where Monitoring, Backend processing andSimulation was mentioned. Among all participants, there were 5%, who hadnever used JavaScript and have no experience with it. These were excludedfrom the JavaScript questions.

38


3.3. Survey Results

This section presents the results of the survey and is divided in three parts.First we present the results about JavaScript in Section 3.3.1, followed byNode.js specific answers, presented in Section 3.3.2. Finally, the results aboutthe questions related to the participant’s companies are presented in Section3.3.3.

3.3.1. Results about JavaScript

For getting an overview about the volume of JavaScript code, produced in anaverage project, the participants were asked, how much of the code in theirprojects is written in JavaScript in average, measured in lines of code. Theywere able to give the answers in ranges of ten percentages or to answer thatall or none JavaScript was used. Figure 3.1 illustrates the results in form of abar chart.

1%#

23%#

11%#10%#

3%#

6%#

8%#

4%#

11%#

6%#7%#

5%#

0%#

5%#

10%#

15%#

20%#

25%#

0%#

1%#,#10%#

11%#,#20%#

21%#,#30%#

31%#,#40%#

41%#,#50%#

51%#,#60%#

61%#,#70%#

71%#,#80%#

81%#,#90%#

91%#,#99%#

100%#

%"of"projects"

%"of"JavaScript"code"

Figure 3.1.: Survey Results - The average volume of code in JavaScript

There were only 1% of projects, where none JavaScript was used. The biggestgroup of projects had 1% to 10% of the code, written in JavaScript. Taking thearithmetic average of each group, there is an average percentage of JavaScriptcode within projects of ∼44%. On the very right there are the projects shown,which are programmed fully in JavaScript, with an amount of 5%.

39


Table 3.4 shows the editors, used for JavaScript programming, whereat multi-ple answers were allowed.

Editor n % of allSublime Text 38 38%Eclipse 30 30%Vim 28 28%Notepad++ 14 14%Visual Studio 14 14%TextMate 9 9%Aptana 8 8%NetBeans 8 8%Emacs 7 7%IntelliJ 7 7%WebStorm 7 7%Komodo 5 5%Other 14 14%

Table 3.4.: Survey Results - The usage of editors for JavaScript

The most popular editor for all participants was Sublime Text, with a usageof 38%, followed by Eclipse (30%) and Vim (28%). The Cloud9 IDE wasmentioned two times and is included in the 14% of “Other”. For analyzingHypothesis 1 (JavaScript developers are not satisfied with the current toolsupport), we asked, whether the participants are fully satisfied with their edi-tors. About 53.7% of them agreed, so it seems, that the hypothesis cannot beconfirmed. In contrast, there were only ∼30.5% who were not fully satisfied,whereat ∼15.8% gave no answer to this question. All those participants, whowere not fully satisfied were asked to give the features they are missing in theireditors. In total, there were 25 answers. Most of them criticized missing codecompletion support, debugging and refactoring capabilities. It was also stated,that the syntax highlighting is not sufficient and that there is a need, for bettercode navigation functionalities.For comparing the satisfaction between the different editors, we calculatedthe coefficient between the count of unsatisfied and satisfied answers for eacheditor, i.e. a higher value means, that there are more people satisfied withan editor than unsatisfied. A value lower than one means, that there weremore unsatisfied people than satisfied ones. The highest values had IntlliJ(5),WebStorm (5), Komodo(4) and Emacs(4). The lowest values were calculatedfor Eclipse (∼0.85), Notepad++(∼0.83) and NetBeans(0.75). WebStorm is a

40


special IDE for JavaScript89 and IntelliJ offers special Web Development ca-pabilities for JavaScript and CoffeeScript90, which applies for Komodo too91.This might was a reason for the high satisfaction with these editors. Emacs isan extensible and customizable text editor92. Developers using Emacs maybeadapt it for their needs and extend it with special JavaScript functionalities,which may lead to this high satisfaction. Eclipse has a quite low satisfaction, infact, there are more unsatisfied people than satisfied ones. The reason for thismight be, that people programming in Java with Eclipse use it for JavaScript,too. They maybe expect all the features they have for Java also for JavaScriptin Eclipse’s standard configuration, which is normally not the case. The samemight apply for NetBeans.

For getting an overview about the impressions of JavaScript we provided ninestatements, where the participants were asked to judge on a Likert scale. Fig-ure 3.2 shows the judgement about the first statement related to JavaScript’ssyntax.

24.2% strongly agreed to “I like the syntax of JavaScript” and 41.1% agreedwhich makes in sum an approval of the statement of 65.3%. Therefore, Hy-pothesis 2 could not be confirmed. In contrast, there were only ∼30%, who didnot like the syntax. For analyzing the current development of other languages,compiling to JavaScript, like CoffeeScript or Typescript, we asked some ques-tions about them. CoffeeScript seems to be the more popular language. 88.4%of the participants, have already heard about it, where Typescript was onlyknown by 54.7%. Although, CoffeeScript is widely known, it was not used alot within the projects of the participants. ∼80% of the projects does not useit at all, ∼8% use it for less than the half but at least for 1% of their JavaScriptcode and ∼5% for more than the half but less than for all. There were about7% of the projects using CoffeeScript for all their JavaScript code. In addi-tion, the participants were asked to give some reasons for using CoffeeScript.In the eyes of the participants, the major advantage of using it was a bettersyntax, but being almost one to one equivalent to JavaScript at the same time.It was mentioned, too, that it provides a better object-oriented model thanJavaScript and is more like Ruby or Python, which makes it easier to learn

89cf. [Je13b]90cf. [Je13a]91cf. [Ac13]92cf. [Fr13]

41


for programmers, having experiences with these or other object oriented lan-guages. It was mentioned additionally, that it makes the code more readable,easier to maintain, shorter and more expressive for some statements. Whilewe received 14 answers, describing the reasons for using CoffeeScript, therewere 58 reasons given for not using CoffeeScript. A lot of the participants justread about it or did not have the time to test it yet. The biggest statementagainst CoffeeScript was, that it adds another layer in between. This leads to afragmentation of the community, inconsistent coding styles, less tool support,adds another build step and makes it harder to find good developers. It wasmentioned by eleven participants, that they prefer the JavaScript syntax as itis and that they do not see any advantage of using CoffeeScript. It was alsostated, that it is just useless. Some said that it is easier to write, but harderto read than JavaScript.Another more often occurred opinion was, that it is harder to debug, and thatit is important to debug in the same language as you write the code. It wasalso stated, that it is too much effort to learn, too new or that it just doesnot fit into the project. Two participants did not like the concept of code gen-eration and stated, that CoffeeScript is obscure. The participants, not usingCoffeeScript at the moment, were asked whether they are planning to use it infuture. Three of them (∼4.5%) are planning to do so, in contrast there were 50participants (∼74.6%) who do not, whereas the other 20.9% gave no answer.As already mentioned, TypeScript was less known than CoffeeScript, eventhough ∼54.7% of the participants already heard of it. There was one person,using TypeScript for 1% to 49% of its code. It was stated, that it is “easier forcomplex projects”. 42 reasons were given why TypeScript was not used yet.A majority said, that there was no time, or that they just played around withit a bit. Another widely stated argument was, that it is too new or not stableenough. It was mentioned a lot, that there is no need for types in JavaScript,in contrast, the dynamic typing is one of its strengths that would be elimi-nated by TypeScript. Six people did not like the fact, that it is developed byMicrosoft and others complained, that there is no IDE supported despite ofVisualStudio, which is only available for Windows. Additionally, there weresimilar statements as about CoffeeScript: There is no advantage or no need,it adds another layer and build step and that pure JavaScript is better respec-tively it is important to know JavaScript well. In contrast to CoffeeScript,there were six people, who are planning to use TypeScript in future and 33

42


who does not. The reasons for using it in future were mostly a positive impactof types especially for documenting and IDE support. One participant men-tioned, that he will use it only, if there will be a good IDE support for Linuxand Mac operating systems, too.

24.2%%

41.1%%

21.1%%

8.4%%

5.3%%

0%%

10%%

20%%

30%%

40%%

50%%

60%%

70%%

80%%

90%%

100%%

I"like"the"syntax"of"JavaScript"

No"answer"

strongly"disagree"

disagree"

agree"

strongly"agree"

Figure 3.2.: Survey Results -Judgements aboutJavaScript Syntax

In sum, both, CoffeeScript and TypeScriptare already well-known. Even though, theyare not used a lot as the participants just likeJavaScript itself or they think that it is betterto write it as it is, without adding a new buildstep or layer in between. This also indicates,that Hypothesis 2 was not correct. Addition-ally, it was a lot mentioned, that there is aneed of improvement for the tool support forboth, CoffeeScript and TypeScript.

For analyzing Hypothesis 3, we made a closerlook to the maintainability of JavaScriptcode. Figure 3.3 shows another four judge-ments of statements about JavaScript relatedto maintenance in a pillar chart.

The first statement was directly related tomaintenance and the judgement is shown atthe very left within the figure. 8.4% of theparticipants strongly and 43.3% agreed, that

JavaScript code is hard to maintain which makes in sum an agreement of over50%. Only 44.2% disagreed on this, which gives a first indicator for Hypoth-esis 3 being wrong. To go deeper in the maintenance topic, we did furtherstatements where the participants were asked to judge about. As mentionedin Section 3.2, [Sp06] stated, that the four attributes of maintainability of theISO software engineering product quality standard corresponds to four phasesof a maintenance change. These are analyzability, changeability, stability andtestability. Analyzability refers to locating the cause of an error and locatingthe parts of a software, that has to be modified for implementing new fea-tures. The easiness of these tasks highly refer to readability of code, whichwe tried to analyze for JavaScript with the judgement about the statement“JavaScript code is easy to read”. The result is presented in the pillar second

43


8.4%%

21.1%%14.7%%

8.4%%

43.2%%

44.2%%

33.7%% 44.2%%

29.5%%

23.2%%

37.9%% 32.6%%

14.7%%5.3%% 8.4%% 10.5%%

4.2%% 6.3%% 5.3%% 4.2%%

0%%

10%%

20%%

30%%

40%%

50%%

60%%

70%%

80%%

90%%

100%%

JavaScript*code*is*hard*to*maintain*

JavaScript*code*is*easy*to*read*

JavaScript*code*is*easy*to*structure*

JavaScript*code*is*hard*to*refactor*

No*answer*

strongly*disagree*

disagree*

agree*

strongly*agree*

Figure 3.3.: Survey Results - Statements about JavaScript related tomaintenance

from left within Figure 3.3. 65.3% of the participants agreed to this including21.1%, who even strongly agreed. On the other hand, there were 28.5%, whodisagreed, including 5.3% who strongly disagreed. An important part of an-alyzability that also influences the readability is the visual structure of code.14.7% of the participants strongly agreed and 33.7% agreed to the statement“JavaScript code is easy to structure”. In sum, there is an approval of thisstatement of 48.4% of the participants, while there are 46.3% of the partici-pants, who disagree on this. Even with weighting the strong statements more,there is no distinct opinion about the easiness of structuring JavaScript code.Nevertheless, the agreement prevails slightly so, there is a positive influenceon readability, which has a positive impact on JavaScript’s maintainability.

Despite analyzability the changeability influences the maintainability, too.Changeability refers to the easiness of implementing specified modifications93.For analyzing this, we stated “JavaScript code is hard to refactor”. The resultis not distinct, too, although about 52.6% of the participants agreed, whereas42.6% disagreed, so, the agreement prevails slightly which positively influencesthe maintainability of JavaScript.93cf. [Sp06, p. 403]

44


For improving the software quality, it is important to have tools and frame-works, supporting the testing, which has an impact on maintainability too.The survey showed, that ∼42.1% were using testing frameworks for theirJavaScript code and∼46.3% did not. The most popular testing frameworks arelisted in Table 3.5 where the participants were asked to name the frameworksthey are using. In total, there were 69 answers given.

Framework n % of the used frameworksJasmine 15 ∼21.7%Mocha 13 ∼18.8%QUnit 7 ∼10.1%Vows 5 ∼7.2%Nodeunit 3 ∼4.3%JSUnit 3 ∼4.3%Sinon.JS 3 ∼4.3%Phantom.JS 3 ∼4.3%Expect.js 2 ∼2.9%YUI Test 2 ∼2.9%Chai 2 ∼2.9%Other 11 ∼15.9%

Table 3.5.: Survey Results - JavaScript testing frameworks

Jasmine was used by ∼21.7% of the participants, using a testing frameworkand builds the top of the usage of testing frameworks, followed by Mocha(∼18.8%) and QUnit (∼10.1%).

After all, Hypothesis 3 seems to be not correct. It was shown, that the majorityof the participants were satisfied with their tool support. They also liked thesyntax of JavaScript and also agreed to a good readability and in general toa good maintainability of it. This is supported by a wide usage of testingframeworks for JavaScript.

To show whether there is a correlation between the application of a testingframework and judgments about the maintainability of JavaScript we applieda Pearson’s χ2 test on those values. The calculated value of p = 0.008 confirmsa statistically high significance between these two values, i.e. the usage of aJavaScript testing framework positively influences the maintainability.

Figure 3.4 shows the remaining three statements related to the general impres-sion about JavaScript. Participants, who not gave an answer were excluded

45


from this figure to make it more readable. This makes the pillars not compa-rable to each other, as they are based on a different underlying set.

63.0%& 62.6%&

29.2%&

27.2%& 28.6%&

61.1%&

7.6%& 7.7%&2.8%&

2.2%& 1.1%&

6.9%&

0%&

10%&

20%&

30%&

40%&

50%&

60%&

70%&

80%&

90%&

100%&

JavaScript*is*important*for*my*projects*

The*general*importance*of*JavaScript*will*rise*in*future*

I*am*fully*sa:sfied*with*the*performance*of*JavaScript*

strongly*disagree*

disagree*

agree*

strongly*agree*

Figure 3.4.: Survey Results - General statements about JavaScript

As it is shown at the very left in Figure 3.4, JavaScript is important for the ma-jority of the participants. About 90% agreed to this in total whereas 63% evenstrongly agreed to this statement. The picture is almost the same for the futureimportance of JavaScript, where also about 90% agreed, that the general im-portance of it will rise whereas 62.6% of the participants even strongly agreed tothis. This confirms our Hypothesis 4 (The general importance JavaScript willrise in future). The third pillar shows, that the majority is satisfied with theperformance of JavaScript, which more relates to the respective interpreters.

After all, we gave the participants the possibility, to give some general opinionsand statements about JavaScript. Some selected cites out of the 16 statementscan be found in Section A.2.

3.3.2. Results about Node.js

Node.js was widely known by the participants. 88% of them have alreadyheard about it, mostly via internet news (∼54.6%), whereas “Hackernews” wasmentioned explicitly a few times. Despite of that, twelve people heard aboutit the first time over friends and ten in business.

46


About 68.2% of the participants, which is an amount of 60 people, activelydevelop with Node.js or it is used in one of their projects. Our next questionasked the context of the projects, whereas multiple answers were allowed. Table3.6 lists the respective results.

Project context n % of projectsPrivate 45 45%Business 43 43%Open Source Project 21 21%University/Research 2 2%

Table 3.6.: Survey Results - Context of the Node.js projects

45% of the projects were done privately and 43% for business. 21% of theprojects were open-source projects and 2% of the projects were related toresearch. As only 60 people answered the question, the number of projects(111) was quite high. In average every participant had almost two projects inparallel. Next we asked for the number of people, working in these projects.The result is illustrated within Table 3.7.

# of projects % of projects # of people22 41.5% 112 22.6% 36 11.3% 24 7.5% 53 5.7% 43 5.7% 101 1.9% 81 1.9% 151 1.9% 80

Table 3.7.: Survey Results - Number of people within projects

On the majority of projects, there was only one person working. 22.6% hadthree people working on so it seems, that the projects tend to be smaller. Thebiggest project had 80 employees, so there was a quite big project, too, thatuses Node.js. In average there were 14.2 people working on one project.Subsequently, the participants were asked to give the starting date of theirprojects. Figure 3.5 shows the number of projects started per month of year.

47


0"

1"

2"

3"

4"

5"

6"

7"

8"

2009,10"

2009,12"

2010,02"

2010,04"

2010,06"

2010,08"

2010,10"

2010,12"

2011,02"

2011,04"

2011,06"

2011,08"

2011,10"

2011,12"

2012,02"

2012,04"

2012,06"

2012,08"

2012,10"

Number"of"Projects"

Figure 3.5.: Survey Results - Beginning of the projects

The oldest project already started in October 2009. Node.js came out a bitlater as it was presented first in November 2009 at JSConf EU94. Therefore,this date might be wrong. Nevertheless, the majority of projects was quiteyoung. 50% of them started after March 2012. Measured to the 31.12.2012the average project age is about 349 days. At next, we were interested in thekind of projects the participants are developing. Table 3.8 shows the respectivekinds with their amount.

Kind of Project n # of projectsWeb Application 52 ∼61.9%Command Line Tool 11 ∼13.1%Framework 10 ∼11.9%Server 3 ∼3.6%Embedded 2 ∼2.4%Browser Game 1 ∼1.2%Desktop Application 1 ∼1.2%Telephony IVR 1 ∼1.2%Other 3 ∼3.6%

Table 3.8.: Survey Results - Kind of projects

It turned out, that the majority of projects are Web Applications with anamount of about 61.9%. As the gap to the subsequent kinds is quite distinct,Web Applications seem to be the common use case for Node.js. Despite ofthat, there is a variety of other project kinds. About 13.1% of the projectswere Command Line Tools and about 11.9% of the participants projects build

94cf. [Da11]

48


frameworks. There were also ∼3.6% who build servers and ∼2.4% who workedin the area of embedded devices. One participant also built a Desktop Appli-cation and there was one, building a telephony interactive voice response withNode.js. 38 participants also provided a description of their projects. Most ofthem were related to web applications focussing on prototyping, games, confer-encing, network analysis, monitoring and realtime functionalities. One projecthelps to work with asynchronous code by providing a flow control library andanother one controls remotely the arduino platform.

For analyzing the reasons for Node.js being used, we asked for the reasons forchoosing Node.js for these projects, where we received answers from 49 partic-ipants. The biggest reason for choosing Node is performance and simplicity.A lot of the participants felt already comfortable with JavaScript and there-fore used it also on the server side. It was often stated, that this was a goodfit for web applications, as the client was programmed in JavaScript and thedatabases were using it, too. It was also mentioned, that it is good, if thereis no “phase-shift” when switching from programming the client in JavaScriptto the server side. In this context it was also said, that there is a possibilityof code reusability on the client and the server side. Big reasons for choosingNode were also its capabilities related to realtime web applications. A fewpeople liked its evented and non-blocking nature and evidenced Node a goodscalability and concurrency behavior. The low time to market of Node seemsto attract especially startups, too. It was also mentioned, that node was chosenjust out of curiosity, because it is open-source, its fun and it makes low-levelHTTP usage easy. The easy integration of C/C++ libraries, the strong com-munity, the handling of high volume of requests and the easiness to maintainwas also given as reasons for choosing Node.

About 35.7% of the participants not using Node, considered to use it for oneof their future projects but decided against because of several reasons. Onewas, that it is hard to find experienced staff and that there is lack of enterpriseexperience and enterprise support, which is analyzed in the following, too.One participant mentioned a personal risk when choosing Node (“You won’tget fired for choosing J2EE but NodeJS”). The others found better fittingtechnologies, haven’t got the time to learn it or found too many bugs. About64.3% of the people not using Node did not consider to use it at all. For this wereceived nine reasons, whereas the biggest was, that there is no need for a newtechnology or that there is no customer requirement. Four participants did not

49


like JavaScript and two mentioned, that they felt comfortable with Python andhad no need for using Node. 25% of the participants, who currently did notuse it, were planning to use it in future, whereas about 64.3% did not.

For getting an overview of used frameworks on top of Node and to achieve atendency of typical use cases for it, we asked which frameworks the participantsuse. About 18.3% of the participants used plain Node.js and ∼81.7% madeuse of frameworks, which are shown in Table 3.9.

Framework n # of participantsExpress 40 40%socket.io 5 5%connect 4 4%flatiron 2 2%Other 17 17%

Table 3.9.: Survey Results - Usage of frameworks on top of Node.js

The high usage of express, a web application framework for node95 (40% ofthe projects), connect, a middleware framework96 (4% of the projects) andflatiron, a web application framework, too97 (2% of the projects) confirms thetypical use case of web applications for Node. The realtime capabilities ofNode were mentioned a lot within the questionnaire, which is also shown bysocket.io being used by 5% of the projects, which is a framework for “realtimeapps” for Node98. Despite of them, there were 17 other frameworks mentioned,but participants stated, that they use a lot of more frameworks. These otherframeworks include despite of others web application frameworks like Derby orMeteor, realtime frameworks like SocketStream or nowJS and object modelingframeworks like mongoose.

For getting an assessment about Node.js and its future, we provided threestatements, where the participants were asked to judge on a Likert scale. Theresults of the judgements are illustrated in Figure 3.6.

As it can be seen, Node.js was very important for the projects of the partic-ipants. 47.7% of the them strongly agreed to the provided statement related

95cf. [Ho12]96cf. [Se12]97cf. [No12]98cf. [Ra12b]

50


47.7%%54.5%%

30.7%%

20.5%%

26.1%%

37.5%%

12.5%%

5.7%%

3.4%%

9.1%%3.4%%

3.4%%

10.2%% 10.2%%

25.0%%

0%%

10%%

20%%

30%%

40%%

50%%

60%%

70%%

80%%

90%%

100%%

Node.js(is(important(for(my(projects(

The(general(importance(of(Node.js(will(rise(in(

future(

I'm(fully(sa;sfied(with(the(performance(of(

Node.js(

no(answer(

strongly(disagree(

disagree(

agree(

strongly(agree(

Figure 3.6.: Survey Results - Statements about Node.js

to the project importance and 20.5% agreed. From the participants point ofview, the general importance of Node.js will rise in future. More than the halfof them strongly agreed to this, which is a quite distinct result. Performancewas one of the main reasons for choosing it for the projects. In the next ques-tion we explicitly asked to judge this. One fourth did not give an answer here,so, there were many people not sure what to judge. For the participants, whogave an answer, the result is quite clear. Here only 6.8% of them disagreedto the statement “I’m fully satisfied with the performance of Node.js”, the restagreed to this.

In order to analyze our Hypothesis 5, “Node.js is suitable for enterprise ap-plications”, we asked the participants about their opinion about its enterprisereadiness. About 64.8% of them agreed to our hypothesis. The most occurringreasons for the enterprise readiness of Node.js was its scalability, performance,stability and a short time to market respectively a shorter development time.The participants emphasized its simplicity and mentioned a lot, that it is pos-itive to have one single language for both, the client and the server side, whichmakes developers able to switch and also simplifies the finding of new devel-opers. A few participants also said, that they do not see any reason, why itshould not be enterprise ready. From the participants point of view, Node.jshad a good and large community, strong core developers and provides a lot of

51


libraries and frameworks accessible over the node package manager. It was alsoreasoned, that Node is responsive, open, extensively tested, efficient, clean andthat its easy to build modules and easy deployable in the cloud, which makesit enterprise ready. It was mentioned, too, that enterprise readiness is morerelated to a good development process, than to the language itself. Anotherparticipant referred to LinkedIn as an enterprise, already using Node.js produc-tively. 13.6% of the participants stated, that Node.js is not enterprise ready.Reasons for this, given by the participants were missing stability and a lack ofenterprise experience and support. One participant mentioned, that it is hardto find experienced staff for Node.js. The maintainability was criticized, too.Despite of that, it was stated, that it is hard for libraries to keep up-to-date tothe quick evolution of Node and that there is no good way to handle multipleNode.js instances. Another reason was, that legacy code is mostly writtenin other language, which makes Node.js not to a good fit. Additionally, oneparticipant mentioned, that there is no connectivity to enterprise databases.Despite of these it was claimed, that JavaScript is not safe and that open-source libraries have proven to be unstable. It was criticized, too, that eventedIO complicated everything.This brings us to the next question, which asks, what functionalities the par-ticipants are missing currently. It was mentioned that there is a lack of threadsand that the usage of multiple cores of a CPU is not supported well. Addition-ally, one participant missed communication features for distributed Node.jsprocesses. Database related features were mentioned three times. The partic-ipants wished an ORM like Active Record, a graph database engine, a genericdatabase connection and a native HBase client to be implemented. It wasalso stated, that authentication and authorization features are missing at themoment. In addition there was a SSH and an incoming mail server implemen-tation, a higher level file system API, OpenCI support and a reference contentmanagement system implementation stated. At last, the participants werenot satisfied with the current debugging functionalities and wishes, to have agraphical debugger included in one major IDE. Furthermore, they claimed abetter behavior driven development style testing framework.

At last we gave the participants the possibility, to state general commentsabout Node.js. Some selected ones can be found in Section A.3.

52


3.3.3. Background Information about the Companies

Within the third part of the questionnaire, we asked a few questions about thecompanies, the participants are working in. Some of the results were alreadypresented in Section 3.2, whereas the remaining ones are presented here.Within this third part, we asked the participants how many employees theircompanies have, where we received 73 answers in total. It turned out, thatthere was an average number of employees of 2495. In this context, we ana-lyzed, which participants actively develop with Node.js or where it is used inone of their project in a business context. The number of companies, wherethis applied was 32. Calculating the average number of employees here givesan amount of ∼1100, so companies using Node.js tend to be smaller.A similar tendency can be seen with the year of foundation of the companies.The average year from 68 answers was ∼1986. Taking only the companies,that use Node.js, the average year of foundation is ∼2004, therefore it seems,that younger companies use Node.js rather than older ones.At last we asked, if the participants think, that the company they are work-ing in is an early adopter of new technologies. 32% agreed to this, 26% evenstrongly agreed, 26% disagreed and 5% strongly disagreed. So, the majorityof people, taking part in the survey are working in companies that are earlyadopters. Taking again the companies, that use Node.js, there were ∼34.2% ofthe participant who would strongly agree to the statement, that their companyis an early adopter, 43.0% agree, whereas there are ∼19.5% who disagree and∼2.4% who strongly disagree to this statement. It turned out, that companiesusing Node.js tend to be early adopters of new technologies.

3.4. Survey Conclusion

The survey showed, that JavaScript is used a lot in general. More than the halfof the participants were satisfied with its current tool support, albeit, thereare some features missing, like debugging, code completion or code navigation.Most of the participants liked the syntax of JavaScript and do not use thenewly developed languages TypeScript or CoffeeScript. It was shown, that themajority of the participants is satisfied with JavaScript’s maintainability.About 42% of the participants are using testing frameworks for their JavaScriptcode. It turned out, that there is a statistically high significance between

53


the application of testing frameworks and the judgement about JavaScript’smaintainability i.e. the usage of a JavaScript testing framework positivelyinfluences it.In general, JavaScript has a very high importance for the participant’s projectsand it was shown, that its importance will rise in future.

Node,js is already widely known. Projects, that makes use of it, tend to besmaller and younger. The typical use case for it are web applications, which wasshown by the participant’s projects and the usage of typical web applicationframeworks on top of Node.js. More than the half of the participants said, thatNode.js’ importance will rise in future. Furthermore, a majority confirmed theenterprise readiness of it.

54

4. Design of the Collaborative Editor

This chapter introduces the design of a collaborative editor that enables dif-ferent forms of collaboration and realtime capabilities. To do so, it followsa bottom-up approach, starting with a high-level consideration of the systemfollowed by describing each part in detail. Chapter 5 continues by describinga prototypical implementation of the presented design.Section 4.1 shows the use cases, that are realized by the editor. Section 4.2gives a brief introduction to the realtime architecture, the collaborative editorfollows. These two sections build the basis for an architectural overview, pre-sented in Section 4.3, which is followed by the description of the client-designin Section 4.4 and the server-design in Section 4.5.

4.1. Use Cases

This section presents the use cases for the collaborative editor prototype. Theyare grouped by their central topic into user centric use cases (Section 4.1.1),document centric use cases (Section 4.1.2) and dashboard centric ones (Section4.1.3). This grouping supports the understanding of the respective contexts.Figure 4.1 illustrates all of them within a use case diagram. The subsequentsections present all use cases with a detailed description.

55


Figure 4.1.: Use Cases of the collaborative editor

4.1.1. User-centric use cases

4.1.1.1. Show online users

Description Commonly, there are multiple users active on the collaborativeeditor. For getting an overview, the user interface provides a list of allusers who are currently online.

Pre-condition The user is logged in.

56


Basic Flow of Events

1. The user logs in

2. The user goes to the collaborative editor start page

3. The user sees the online collaborators

Post-condition All users, who are currently online, are shown in the userinterface.

4.1.1.2. Invite user to collaborative editing

Description This use case enables the user to invite other users to workcollaboratively on a document.

Pre-condition The user is logged in; there is at least one other user onlinewithin the collaborative editor; there is at least one document.


1. The user logs in


3. The user sees a list of all online collaborators

4. The user clicks on one of these users to open the context-menu

5. The user chooses “Invite to collaborative work”

6. A list of all available documents is presented to the user

7. The user selects one of these documents and clicks on the “Inviteand open” button

8. The user gets automatically forwarded to the chosen document

9. The chosen collaborator receives a chat message that she was invitedto work collaboratively on a document. The chat message containsa link to the document.

Post-condition The inviting user sent the invitation and looks at the chosendocument. The collaborator received the invitation in form of a chatmessage including a link to the document.

57


4.1.1.3. Chat with user

Description One important collaboration feature of the editor is the chatfunctionality, which enables users, to exchange text messages

Pre-condition The user is logged in; there is at least one other user withinthe collaborative editor.


1. The user logs in


3. The user sees a list of all online collaborators

4. The user clicks on one of these users to open the context-menu

5. The user chooses “Talk to”

6. A chat window gets opened automatically

7. The user types a new message and sends it

Post-condition The chat-partner was notified about the new message and isable to answer

4.1.1.4. Show activity feed

Description The use case “Show online users” already displays all users, whoare currently online. This use case additionally provides an activity feedfor each user indicating her current activity e.g. “Is currently editingDocument 5”.

Pre-condition The user is logged in; there is at least one other user online.


1. The user logs in


3. The user can see the current activity of the other users

Post-condition The activity feed shows the current activity of another user

58


4.1.2. Document-centric use cases

4.1.2.1. Show document overview

Description This use case presents all the currently available documents,including their names, the date of the last modification and the actions,that can be executed on this document like review, edit or delete.



1. The user logs in


3. The user chooses the document overview within the user interface

4. All the documents are presented

Post-condition All currently available documents are presented to the user.

4.1.2.2. Create document

Description This use case enables the user to create new documents.

Pre-condition The user is logged in; the use case “Show document overview”was executed.


1. The user clicks on the the respective button for adding a new doc-ument within the document overview screen

2. The user types in the name for the new document and optionallyadds some tags to it

3. The user confirms the creation

Post-condition The new document was created successfully; the documentis automatically visible for all other online users.

59


4.1.2.3. Edit document

Description This use case enables the user to edit an existing document.There is always one user able to actively write on the document at thesame time. All subsequent users, opening the same document respec-tively executing this use case, are automatically set as reader.

Pre-condition The user is logged in; the use case “Show document overview”was executed; the document was created.


1. The user clicks on the the respective button for editing an existingdocument within the document overview screen

2. The document gets opened and is ready for collaborative editing

Post-condition Document was opened and is ready for collaborative editing.

4.1.2.4. Switch writer

Description There is always one user able to actively write on a documentat the same time. All other users are automatically set as readers. Thisuse case enables the current writer, to hand on this role to another user.

Pre-condition The user is logged in; the use case “Edit document” was exe-cuted; the user is currently the writer.


1. The user clicks on the the drop down menu “Select other writer” tochoose another user who has currently the same document opened

2. The user clicks on the “Go”- button

3. The user is set automatically as reader, whereas the chosen user isautomatically set as writer

Post-condition The one user, initiating the switch is now set as reader. Thechosen user is now set as writer.

60


4.1.2.5. Review document

Description This use case enables the user to see the changes which weredone since the creation of the document per user.

Pre-condition The user is logged in; the use case “Show document overview”was executed, the document was created.


1. The user clicks on the the respective button for reviewing an existingdocument

2. The user gets the first state of the document presented, just afterits creation

3. The user interface offers the possibility to walk through all changesdone by the different users until the current state of the document

Post-condition -

4.1.2.6. Delete document

Description This use case enables the user to delete existing documents.

Pre-condition The user is logged in; the use case “Show document overview”was executed; the document was created.


1. The user clicks on the the respective button for deleting an existingdocument

2. The user can confirm or abort the action

Post-condition The chosen document was deleted successfully. The removalof the document is automatically propagated to all other users.

61


4.1.3. Dashboard-centric use cases

4.1.3.1. Show dashboard

Description The dashboard presents an overview of important figures in-cluding the number of currently available documents and the number ofonline users. Theses figures are automatically updated, if they change.



1. The user logs in


3. The dashboard is shown

Post-condition All elements within the dashboard are presented to the user.

4.1.3.2. Show number of documents

Description This number provides an overview about the amount of docu-ments available within the editor.

Pre-condition The user is logged in; the use case “Show dashboard” wasexecuted.


1. The dashboard shows the number of documents

Post-condition The number of documents is presented within the dashboard.

4.1.3.3. Show number of online users

Description Commonly, there are multiple users active on the collaborativeeditor at the same time. For getting an overview, the number of currentlyonline users is presented to the user.

Pre-condition The user is logged in; the use case “Show dashboard” wasexecuted.

62



1. The dashboard shows the number of currently online users

Post-condition The number of currently online users is presented within thedashboard

4.2. The Realtime Architecture

In [Ma11], Alex MacCaw describes an architecture for realizing realtime webapplications. As a pre requirement, the application’s client side should bemodeled following the Model-View-Controller-pattern that divides it into threeparts. The model only holds data. It does not know anything about the con-troller or the views, it just keeps the pure data. The view is the part, the userdirectly interacts with. It should also be decoupled from the controller and themodel and it has no business logic inside. It is just responsible for presentingdata and enabling user interaction. The last part of this architectural patternis the controller. It holds the business logic and can be seen as the connectorbetween models and views. If a user acts with the view and clicks on a buttonan event is fired that is catched by the controller that does the logic that needsto be done for processing this event properly.This brings us the the next important characteristic of a realtime architecture:it is event-driven. Typically, this means that it is driven by user interactionswhich is in our context, for example, the creation of a new document or justthe appearance of a new user. All these actions result in events that may needto be propagated through the system and sent to the other clients. [Ma11]states two important things to think of during the creation of a realtime ap-plication. The first one is to decide which models need to be realtime whichleads to the decision which data need to be propagated trough the system. Thesecond one is to decide, who needs to be notified about these changes. This ismostly realized with the publish-subscribe pattern which is also used withinthe collaborative editor in a special way. Here, a client subscribes to differentchannels that enables the server to notify groups of clients respectively theseones, that subscribed to a single channel. If only one user is present in a chan-nel, only the one user gets notified, which can be seen as direct message fromthe server to a single client. If multiple users subscribed to one single channel,a server is able to send messages to a group of clients. Both methods are used

63


within the collaborative editor.This brief introduction to the realtime architecture will lead the whole designand development of the collaborative editor, presented in the following.

4.3. Architectural Overview

A major requirement for the collaborative editor prototype is the integrationinto Tricia, that was introduced within Section 2.5. Given additionally thedesign goal of a realtime architecture, presented in Section 4.2 the architecturepresented in Figure 4.2 was developed.

Figure 4.2.: Fundamental architecture of the collaborative editor

At the top, there is Tricia shown, where the collaborative editor is integrated.This integration offers the possibilities that there is no user authentication orauthorization management needed within the prototype as this can be realizedby the access control framework of Tricia as described in Section 2.5. Forgetting access to the collaborative editor, a user needs to login successfullyinto Tricia. Afterwards, Tricia delivers the whole client code via its HTMLinterface to the user who then connects herself to the server. In addition, Triciadelivers information about the logged in user to the client of the prototypeand offers an interface that delivers the documents, stored within. These onesare collected by the collaborative editor and saved in an own database andto make them accessible for the connected clients. The separation betweenTricia and a self-developed server leads to clear responsibilities. Tricia onlydelivers the client code, offers authorization and authentication functionalitiesand provides user information and the initial documents. The collaborativeeditor itself is realized within the client and the server independently. The

64


whole communication between those two parties is asynchronous to realize theevent-driven nature of the system, described within Section 4.2.

4.4. Design of the Client

After the description of the realtime architecture and the architectural overviewof the collaborative editor, this section introduces the client design in detail.To do so it first presents the general kind of the client in Section 4.4.1. Af-terwards, the division into different components is introduced in Section 4.4.2,that also describes each component in detail.

4.4.1. Rich Internet Applications

The client of the collaborative editor is realized as a “Rich Internet Applica-tion” (RIA). RIAs follow the goal of “adding new capabilities to the conven-tional hypertext-based Web”99 which leads to an improvement of the data,business logic, communication and presentation of web applications. The col-laborative editor mostly runs on the client itself, which can result in quickerresponses and optimized communication costs. Furthermore, there is no needfor an additional usage of Tricia. The client code is delivered once whereasthe following communication can be fully realized between the client and theself-written server. Typical for RIAs is also the possibility of bidirectionalcommunication between client and server which means that both parties caninitiate a communication at any time. This optimizes the communication interms of latency100 and is important for enabling the push messages from theserver to the client, described in Section 4.2.

4.4.2. Client Components

For better structuring and for clear responsibilities, the client is divided indifferent components, which are shown in Figure 4.3.

99[FRSF10, p. 10]100[FRSF10, p. 10]

65


Figure 4.3.: Components of the client

The UserInterface-component is the central component of the client. It is thepart the user directly interacts with and it manages the displaying of incomingdata from either the Chat- or IO-component. Furthermore it catches eventsresulting from user interactions and sends them to these two components ifthey has to be propagated to the server or to other clients. The componentsEditor, Chat and IO directly communicate with the server. The Editor-component realizes the integration of an advanced text editor and managesthe live-editing by applying operational transformation functionalities. TheChat-component holds a connection to the chat component of the server andpasses new messages from the server to the client and the other way around.The fourth component IO manages despite of other things the data exchangeof documents or user information.The following sections present each component in detail.

4.4.2.1. User Interface Component

WireframeThe design of the user interface of the collaborative editor is not a major partof this Thesis although, being familiar with it supports the comprehension ofthe following sections. To do so, Figure 4.4 presents a mock-up of the userinterface for getting a first idea on how it looks like.

It consists of three main parts: a header, a navigation bar at the left and anarea at the right for displaying content. The header shows the logo of the

66


Figure 4.4.: Static Wireframe of the User Interface

collaborative editor and the name of the user who is currently logged in withher browser. This is a static area where no changes are done during the wholelifecycle of the client. The navigation bar consists of two buttons that enablethe navigation through the prototype. This area is a static, too. The thirdarea displays the content e.g. the dashboard, the document overview or thedocument that is edited currently so, this is changing dynamically. To see allusers, that are currently available online and to add the possibility of choosingone for chatting or inviting there is another area at the left bottom that showsall online users. This is automatically updated if a new user appears. If auser decides to chat with another one a window pops up which is shown at theright bottom. This contains the whole conversation. Furthermore, incominginvitations are shown here. A detailed description of the client respectivelythe states of the content area is presented in Figure 4.5.

After loading the web page, the dashboard is shown within the content areaand illustrates important figures about the collaborative editor as describedin the use cases within Section 4.1.3. The buttons within the navigation barenable the user to switch between the dashboard and the document overview(the Documents-state), whereas both are shown in the content area. The docu-

67


Figure 4.5.: The lifecycle of the client

ment overview presents all documents, that are currently available for editing.It offers also the possibility to create new or to delete existing documents. Fur-thermore this view enables the user to choose one single document for editingor reviewing purposes. When entering the Editor-state, the respective docu-ment gets loaded from the server and shown in a text editor that makes theediting of this document possible. The Review-state loads the document inall different versions from the server and enables users to comprehend changesthat were done by different users since the creation of the document.

The UserInterface-component follows the Model-View-Controller-pattern asproposed within Section 4.2. As already described, this divides it into threeparts. The model that holds the needed data, the view which is actually thepresentation layer accessed directly by the user and the controller which is theinteraction layer that connects the model and the view101. Each of these partsof the UserInterface-component is presented in the following.

The ModelThe model holds all data needed by the user interface. Figure 4.6 showsthe model, related to documents, in an entity relationship diagram in UMLnotation.

The Document-entity has the three attributes Name, LastModified and Number-OfPeopleEditing. This data is needed for the document overview, therefore,the Document-entity represents the meta information about a single document.The real document content, the rich text, is still on the server and gets loaded

101cf. [Ma11, p. 2-5]

68


Figure 4.6.: ERD for Documents

on demand. One document can have multiple tags describing it, which isrepresented by the Tag-entity. All documents are kept within the Documents-entity.

Another entity within the model is the User-entity which is needed for multiplepurposes. It is illustrated in Figure 4.7.

Figure 4.7.: ERD for Users

Every instance of the User-entity represents a user within the system. Allthese instances are kept in the OnlineUsers-entity which act as data sourcefor the view, that shows all online users. Such a User-entity is also used toidentify a user uniquely for chatting or inviting to a collaborative work. TheUser-entity has multiple attributes. Name is only used for displaying whichapplies for imgURL, too. This is an URL to an image which is shown nextto the name within the user interface. The EMail-attribute keeps the email-address of a user and identifies each one uniquely. The status informs theother users about the activities, the user is currently performing. This fieldsis used for the activity feed. In addition, there is a unique color for each user

69


which is set by the server. It is used within the collaborative work to giveevery user’s cursor one special color to see the place within the document, theuser is currently working on.Another purpose of the User-entity is for contributing to a document review.The first user who creates a document builds automatically the first versionof it. Each time, another user manipulates the document another review iscreated, so, all modifications done by one user are grouped together to oneversion. This enables other users to always track the changes that were donefor each participating user separately.

For enabling chat conversations within the collaborative editor, the Chat-

Conversaion-entitiy is needed, which is shown in Figure 4.8.

Figure 4.8.: ERD for Chat-Conversations

A ChatConversation-entity has the attributesParnterEmail, PartnerName and Text. Thepartner email address is needed for identification.The combination of this address with the one ofthe user, the instance is based on, uniquely iden-tifies a pair of two persons and therefore also achat conversation. The PartnerName-attribute isonly needed for displaying again. The real con-versation text that both partners write and thatis shown within the user interface is saved withinthe Text-attribute in form of a HTML-formattedstring.Another model, that is needed directly at thebeginning of the user interaction is the Dash-board. Currently, this has only two attributes,

NumberOfDocuments and OnlineUsers.

The ViewsThe views are based on the design of the user interface, shown at the beginningof this section. The following views are used within the collaborative editor:

application-view The application-view is the main view that gets loaded ifa user visits the collaborative editor. It consists of other views loadeddynamically on demand, depending on the client state as described in

70


Figure 4.5. Therefore, it builds a frame for all views within the userinterface.

dashboard-view The dashboard-view is the first view loaded into the app-

lication-view. It presents important figures like the number of onlineusers or the number of documents, currently available within the collab-orative editor.

onlineUsers-view Just as the upper two the onlineUsers-view gets loadedat the beginning. It is positioned at the left and shows dynamically allusers that are currently online.

documents-view This view presents all available documents with their metainformation. Furthermore, it enables the user to create or delete a doc-ument and to navigate to other views to edit or to review a document.It corresponds to the Documents-state, presented within Figure 4.5.

editor-view After choosing one concrete document for editing within the doc-ument overview (documents-view), the editor-view is shown that cor-responds to the Editor-state within Figure 4.5. It shows the documentitself within an editor that enables its editing.

documentViewers-view When editing a document which refers to the Editor-state this view is shown, too. It presents all the users, that are currentlyediting the same document.

chatWindow-view The chatWindow-view appears on demand, either whena user starts to chat with another one or if a chat message comes in.Furthermore, it is responsible for presenting invitations to a collaborativework.

review-view The review-view corresponds to the review-state within Figure4.5. It presents one single document in all its versions that has beenproduced since its creation.

The ControllersThe controllers connect the model with the views and realize the business logic.There are several controllers that realize the client-side functionalities of thecollaborative editor. Each one is presented in the following.

71


Figure 4.9.: User-Controller Figure 4.10.: Chat-Controller

Figure 4.11.: Application-ControllerFigure 4.12.: Review-Controller

The UserController, presented in Figure 4.9 is responsible for managing theonline users. This controller also builds the basis for the onlineUsers-view.It has an attribute called content which holds all the available online users.Therefore, it also realizes the Documents-entity of the model. It also enablescommon operations like the adding of new users or the removal of users thatleft the collaborative editor. Additionally, it offers an operation that enablesthe searching for users by their eMail-address which is used for identifyingone user. The ChatController (Figure 4.10) enables the chat functionalities.To do so it offers three operations. The first one creates a new conversationwith another user that is given via parameter. In a typical workflow, theappendMessage operation would be called multiple times afterwards. Eachtime an other user sends a new chat-message, this operation is called, to showup the new message within the chatWindow-view. The last operation is calledif the user wants to end the conversation and it finally triggers the closing of thechatWindow-view. The ApplicationController shown in Figure 4.11 man-ages the application-view. Its four operations manage the events, thrown bythe view. If a user clicks on another user and decides to start chatting with her,the first operation is called which forwards the request to the ChatControllerwhich applies for the second operation, too. The prepareInvite-operationtriggers the opening of a new window that enables the user to select the docu-ment, she wants to edit collaboratively. If she chose the document, the fourthoperation is called that does the invitation by first, sending an invitation to the

72


respective partner and second, by forwarding the user to the chosen document.

Figure 4.13.: Documents-Controller

The ReviewController (Figure 4.12) man-ages the review-view and is responsiblefor one single document-review. The re-spective attribute documentName refers tothis single document. The operationsetReviewVersionNumber triggers the viewto show the single versions of the document.The DocumentsController manages thedocuments-view and the documents itself byoffering operations that create or delete doc-

uments(addDoc, doDel). It also triggers the view to show up dialogues toconfirm the creation or deletion (createNewDoc, showDelDocWarning). TheDocumentsController itself is shown in Figure 4.13.

4.4.2.2. The Chat- and IO-Component

The Chat- and IO-component are responsible for managing the emitting andreceiving of events through the system. On the one hand they send upcomingevents from the client-side to the server, on the other hand they build theinterface for receiving events from the server.Although, both components have similar tasks they are divided into two dif-ferent components to separate them by their functionalities and to increasethe modularity. In the following, all events that are received or sent by theclient are presented. For shorter descriptions, S stands for the server, C forthe client and cb for a callback function. Table 4.1 describes the events theclients are listening for within the IO-component.

Event Parameter Description

who are you - S wants the identity of C.set colorpalette

palette S sets the colour palette of C.

set color colour S sets the unique colour for C.newDoc document A new document was created.

73


availableTags availableTags S sets the available document-tags for C.a new user ap-peared

user A new client was registered S.

a user left user A client left the collaborative editor.delDoc doc A document was deleted.new tag obj A new tag was added to a document. obj

contains both, the document name andthe new tag.

remove tag obj A tag was removed from a document. objcontains both, the document name andthe removed tag.

new documenteditor

user C is editing a document. Another clientopens the same document and needs to beadded to the list of current collaborators.

editor left thedocument

user C is editing a document. Another client,that was also collaborating at the samedocument, left. This one needs to be re-moved from the list of current collabora-tors.

initial docu-ments sent

- S sent all available documents to C.

set as writer - C is set as writer for the currently openeddocument.

set as reader - C is set as reader for the currently openeddocument.

Table 4.1.: Incoming events to the clients within the IO component

As already mentioned, the IO-component is also responsible for emitting newevents that occur within the UserInterface-component. Table 4.2 shows alloutgoing events that need to be distributed to the server or other clients.

Event Parameter Description

check in user Send the own identity to S .

74


new status status C has a new status that needs to be dis-tributed for the activity feed.

storeAnd-Distribute-Document

document, cb C created a new document. cb is called ifthe server received the event, which trig-gers the creation locally.

delDocument docName, cb C deleted a document. cb is called if theserver received the event, which triggersthe deletion locally.

new tag docName,tag, cb

C added a new tag to a document. cb

is called if the server received the event,which triggers the addition locally.

remove tag docName,user, cb

C removed a tag from a document. cb

is called if the server received the event,which triggers the deletion locally.

new editorjoined

docName,user

C started to edit a document. It sends itsown identity as a new editor.

editor left thedocument

docName,user

C left the edit-screen of a document. Ttsends its own identity to distribute theleaving.

create review docName, cb C wants to review a document. cb iscalled if S processed the review with itas parameter.

choose anotherwriter

email, cb C wants to hand over the writer-role toanother client, identified by the email ad-dress. cb is called, when the new writerwas notified.

Table 4.2.: Emitted events by the IO component

The purpose of the Chat-component is the similar, it emits and receives events.Here, within the scope of chatting. There are only two events in total, manageby the Chat-component. The “send a new message”-event is emitted forsending a new message. It that takes as parameters the respective chat partnerand the text. Furthermore, the Chat-component listens for the event “there

75


is a new message” which is used for a new incoming message. It has the sameparameters: the chat partner and the text that was written by the partner.

4.4.2.3. The Editor-Component

A central part of this Thesis is the realization of a collaborative editor whichenables users to collaboratively work on the same document. All users, thathave the same document opened at the same time, can follow the edits of thesingle writer in realtime. The role of the writer can also by handed over to otherusers. To do so, the basic idea follows the concepts described within Section4.2, too. This means, that the whole process of editing a document is event-driven. The part of the editor the user is interacting with is a rich text editor,that enables the user to not just only insert and edit text, but also includeimages, links, tables or formatted text. The content of the document thatis created with this rich text editor is represented in form of the HypertextMarkup Language (HTML) so basically, every feature that is supported byHTML and the rich text editor itself is possible within the collaborative editor,too.

The process of collaborative writing starts with the user, typing somethinginto the rich text editor. This one changes the underlying HTML documenteach time, the user does changes within the editor. The HTML text is a directrepresentation of the rich text created by the user within the editor. Thistext is now synchronised followed the principles of operational transformation,described in Section 2.1.2. Each time, the underlying HTML text changes, theclient analyses the changes that were done and submits operations that repre-sents these changes to the server. The server actually applies these operationsto its local copy of the document and distributes them to the other clients.This process is illustrated in Figure 4.14.

This proceeding happens at the user, that is currently the writer. For readers,the process is the other way around. They receive the operations, that repre-sent a content change from the current writer from the server. These ones areapplied to the underlying HTML text which updates the content of the editor.Afterwards, the user can see the changes of the current writer.In this form, operational transformation is not doing any conflict resolution.

76


Figure 4.14.: Basic Process of collaborative editing

In fact, there are no conflicts as there is only one writer at any time. Never-theless, the usage of operational transformation has major advantages. On theone side, the transmitted operations only represent the changes that were doneto the underlying document. This keeps the data that needs to be exchangedbetween client and server quite small. On the other side, having operationsas fundamental representation for document changes, makes versioning andreviewing possible.

4.5. Design of the Server

The server is one of the three main parts of the architecture of the collabo-rative editor, presented in Section 4.3. It mainly realizes the management ofclients, the distribution of events through the system and the operational trans-formation backend. As these tasks differ, the server is divided into differentcomponents, too. Figure 4.15 presents an overview of all different componentsof the server.

The Database-component offers functionalities for persisting and reading data.Although, this is not a major task, there are still some important informationthat need to be stored persistently like the documents and their operations.The DocumentManager realizes all functionalities, needed for the documentmanagement like the creation and deletion or the addition or removal of tags.

77


Figure 4.15.: Components of the server

The ConcurrentEditing-component manages all clients, working on docu-ments collaboratively and realizes the operational transformation capabilitiesdescribed in Section 2.1.2. To do so it offers a bidirectional communicationchannel that enables users to receive the operations, done by other users, orto send their own ones. This component is the counterpart of the Editor-component of the client and can be seen as the “server” within Figure 4.14.As already described, the Database-component stores all operations that wereapplied on a document. This enables the ReviewManager-component to createreviews for every document on demand. This is done by starting with the firstversion of the document and applying the single operations step by step.The TriciaConnector-component offers a connection to Tricia and realizesthe import of the currently available documents. The allocation and changingof colors for different users is managed by the ColorManager. In the middle ofFigure 4.3 the App component is shown which is the main part of the server. Itconnects all the other components and manages their integration. Furthermoreit offers a bidirectional communication channel which is used by the client(s)to receive or send realtime data. It can be seen as the counterpart to the Chat-and the IO-component of the client.

78


4.6. Initial Client-Server Communication

Based on the fundamental architecture presented in Section 4.3, the client isdelivered from Tricia once. Afterwards the communication between the clientand the server is autonomously. Nevertheless, there are multiple steps to do, tointegrate the client into the whole system properly. This setup phase exchangesinitial data to make it usable for its user and establishes the awareness of otherclients. The whole procedure is presented within this section.After the client was delivered from Tricia, each one connects itself immediatelyto the server. Figure 4.16 shows the respective flow of asynchronous messagesof the involved parties to setup a new client.

Figure 4.16.: Sequence Diagram for the integration of new users

After the client is loaded, which is after a successfully authentication at Tricia,it connects itself to the server. This is shown in message number one in Figure4.16. The server emits a ’who are you’-event to the client, which answerswith his own identity afterwards (message three). This identity was injected

79


into the client by Tricia. If the server received the identity of the new user,it gets distributed to all other currently existing users with event numberfour “a new user appeared”. Subsequently, the new user receives all existingusers (message number five), the metadata of all currently available documents(message number six), the available tags (message number seven), the initialcolor palette (message number eight) and a unique color (message numbernine) sent.After this initial synchronization, the client is fully integrated into the systemand usable by the respective user.

4.7. Conclusion

This chapter presented a design for enabling realtime collaboration in the con-text of a realtime collaboration tool. There were different use cases described,that are supported by this design. The basis for this is built with the realtimearchitecture. Its main characteristic is that it is driven by user interactionsand therefore by events. Furthermore it claims the application of the Model-View-Controller pattern on the client-side and the Publish-Subscribe patternfor the communication with the server. This makes it easy to distribute theevents through the system and to adept the models of each client to the impactof them.The collaborative editor itself is realized as a so-called Rich Internet Appli-cation and is delivered by Tricia. This chapter introduced the architecture ofthe client and the server part of this tool and made a brief introduction toits user interface. As the whole system is event-driven, the respective eventswere presented, that are used for communicating between the clients and theserver.

80

5. Prototypical Implementation of theCollaborative Editor

This section gives an inside into the implementation of the collaborative editorand presents interesting extracts. The implementation itself follows the design,presented in Section 4. Section 5.1 introduces third-party libraries that areused by both, the client- and the server-side. Subsequently, Section 5.2 presentssome details concerning the client implementation followed by Section 5.4,which does the same for the server.

5.1. Shared Third-Party Libraries

Within the collaborative editor, two major third party libraries are used. Theseare deployed in both, the client and the server side. Therefore, they are de-scribed their own sections. Section 5.1.1 described socket.io, Section 5.1.2presents share.js.

5.1.1. socket.io

Socket.io is a Node.js framework that intends to enable realtime web applica-tions for every browser102. To do so, it abstracts multiple different transportprotocols and offers one WebSocket-like API to access them. The underly-ing transport protocol is chosen depending on the user’s browser. Supportedare WebSockets, Adobe Flash Socket, AJAX long polling, AJAX multipartstreaming, Forever Iframe and JSONP Polling that were already introducedin Section 2.2. This enables socket.io to choose faster transport protocols likeWebSockets for modern browsers and to support older browsers at the sametime by choosing older transport technologies103. All supported web browsers102cf. [Ra12b]103cf. [Ra12a]

81

5. Prototypical Implementation of the Collaborative Editor

are shown in the appendix in Section B.1.

Technically, the realtime communication is realized by listening for events onthe one side and emitting events on the other side. This approach fits ideallyinto the realtime architecture presented in Section 4.2. For illustrating on howthis is implemented with socket.io, Listing 5.1 shows some lines of code fromthe server. This code realizes the first four messages presented in the sequencediagram in Figure 4.16.

Listing 5.1: socket.io example from the server1 socketio . sockets .on(’connection’, function (socket) {2 socket.emit(’who are you’);3 socket.on(’check in’, function(user) {4 socket.broadcast.emit(’a new user appeared’, user)5 //........6 }7 //........8 }

In the first line, the server listens for initial connections from clients, which isrepresented by the connection-event. If such an event occurs, the anonymousfunction within line one is called. This gets a socket as argument passed,which must be used for further communication with this client. The sendingof a new event to this newly connected client is done via the emit-functionof the socket object, which can be seen in line two. Here message numbertwo of Figure 4.16 is shown. Afterwards the newly connected user must bepropagated to all other clients to make her visible in their lists of online users.This is done via the broadcast-function within line four which is also theimplementation of message number four of the sequence diagram.

Another important functionality of socket.io are rooms. Rooms enable thegrouping of clients which means that events can be emitted to a special num-ber of clients, respectively these ones within a room. It can be seen as theimplementation of the channels, mentioned in Section 4.2. In the collabora-tive editor, rooms are used for grouping the clients that edit or view the samedocument. Listing 5.2 shows a code snippet out of this context.

82


Listing 5.2: Code snippet that shows the usage of rooms1 socketio . sockets .in(documentName + ’_editors’).emit(’new document editor’, user);2 socket. join(obj.docName + ’_editors’);

If a new user opens a document, all users that currently have the documentopened are notified about the new participant. This is done via a special groupthat is created for each document. The name of this group is the concatenationof the document name and the string “_editors”. This notification is done inListing 5.2 in line one. If this group does not already exist, it is createdautomatically. Afterwards, the new user joins the group for the editors of thisdocument, too, to get also updates about users that join this group or leaveit. The joining procedure is illustrated in line two with the “join”-function ofthe socket object, that belongs to the new user.

For a clearer separation of the messages, the socket.io connection is multi-plexed. This enables the division of the single connection into multiple ones,which is done in socket.io with different namespaces. Within the collaborativeeditor, the default namespace and a namespace called “chat” is used. The sec-ond one is used for chatting, whereas the default namespace handles all otherevents. These two namespaces are used as interfaces for the Chat- and the IOcomponent of the client, described within Section 4.4.

5.1.2. share.js

Share.js enables the concurrent editing of documents by providing operationaltransformation functionalities. To do so, it realizes multiple functionalities.On the one hand it offers an interface for the clients, which allows the sendingand receiving of new operations. On the other hand it builds the system forthe operational transformation mechanisms.Share.js realizes its interface for connecting clients via so called “wire proto-cols”, whereas two different ones are offered. One is a RESTful web protocolthat enables the user to fetch the document, delete a document and submitnew operations in a RESTful way via HTTP-requests and HTTP-methods.Further descriptions on this can be found in [Ge12d]. The collaborative editoruses the second wire protocol, the “Streaming Protocol”. This offers all func-tionalities but the permanent deletion of documents as the RESTful protocol.In addition it allows the receiving of newly arrived operations as soon as they

83


occur104, which is very important for fitting into the event-driven nature of therealtime architecture of the collaborative editor.The streaming protocol is based on technologies presented in Section 2.2 anduses a JSON message format for the communication. It is realized with thetwo other libraries socket.io (see Section 5.1.1) or BrowserChannel whereasBrowserChannel is currently the standard. Therefore this one is used in the col-laborative editor, too. From a functionality point of view both are comparable.The BrowserChannel library calls itself even “google’s version of socket.io”105

as it is developed by the former Google Wave developer Joseph Gentle andwas used in the GMail chat106.A typical communication of a client and a server using the streaming protocolis illustrated in Listing 5.3.

Listing 5.3: Client-Server communication with the streaming protocol107

1 S: {auth:’90b657dc1498061fb7b974740c21395d’}2 C: {doc:’holiday’, open:true, create:true, type:’text’, snapshot:null}3 S: {doc:’holiday’, open:true, create:true, v:0, meta:{creator:’Sam’, ctime

:1327379131999}}4 C: {v:0, op:[{ i :’Hi!’, p:0}]}5 S: {v:0}6 C: {v:1, op:[{ i :’ there’, p:2}]}7 S: {v:1, op:[{ i :’Oh, ’, p:0}], meta:{...}}8 S: {v:2}

At the beginning of a communication the client connects to the server. Theserver manages each client with a session ID which is generated at the serverand sent to the client within line one. Afterwards, the client opens a docu-ment called “holiday” with the type “text”, meaning, that a pure text is goingto be edited concurrently. Share.js currently supports two document types,text and JSON, whereas the JSON type is unstable at the moment and maychange at any time108. If the document does not exist yet, it should be createdautomatically by the server, which is indicated by create:true . If it doesexist, the client receives a snapshot of the current version. Within line three,the server sends its response to the client. v:0 indicates that the current doc-ument version is 0, meaning, that is was newly created by the server. This is104cf. [Ge12d]105cf. [Ge12b]106cf. [Ge12b]106cf. [Ge12d]108cf. [Ge12c]

84


also the reason why there is no snapshot included in the answer. In addition,the server sends some meta information, like the creator and the creation timeof the document. This was the initialization phase, the real document editingfollows from line four. Here the client sends a new operation that inserts thestring “Hi!” (i:"Hi!") at position zero (p:0). This operation is done on docu-ment version 0, which is also confirmed by the server at line five. The currentdocument version was incremented now. At line six, the client sends a newinsert operation on document version one. This is followed by a message fromthe server, meaning, that there was another client submitting an operation ondocument version one, that inserted “Oh, ” at the beginning of the document(position zero). In the last line, the server confirmed the receiving and applica-tion of the operation. It was applied on the document in version two, thereforethe current document version is three. To do so, the server transformed theoperation from op:[{i:’ there’, p:2}] to op:[{i:’ there’, p:5}] toinclude the changes of the operation submitted by the other client. The finalcontent of the document in version three is now “Oh, Hi there!”.Listing 5.4 shows the case, where another client connects to the server, afterall steps above were done.

Listing 5.4: Client-Server communication with the streaming protocol - A newClient connects109

1 C: {doc:’holiday’, snapshot:null}2 S: {doc:’holiday’, v:3, type:’text’, snapshot:’Oh, Hi there!’, meta:{...}}

Again, the client opens the document and states, that she wants to receivea snapshot of the current document in line one. The answer from the serverwithin line two differs now from that within Listing 5.3. Now, the documentversion is three and the current snapshot of it is delivered to the client.

These were some typical messages exchanged by the client and the server touse share.js and to edit a plain text document concurrently. This form ofcommunication happens a lot when a document is edited collaboratively. Theone writer continuously sends new operations to the server which applies themto his local copy. These operations get additionally distributed to all clients,that apply them to their copy, too.

108cf. [Ge12d]

85


5.2. Prototypical Implementation of the Client

This section presents some details about the client implementation. Section5.2.1 introduces all modules and libraries and describes the building of modulesin detail. Section 5.2.2 introduces the implementation of the user interface,followed by some implementation details about the Editor-component andthe editor overview in the following sections.

5.2.1. Modularisation and libraries

The implementation of the client has a big code basis and makes use of alot of third party libraries for enabling special functionalities. To reduce thecomplexity, the code is divided into different modules. Figure 5.1 shows allused libraries and self-written modules whereas all third party libraries arebriefly explained in the appendix in Section B.2.

Figure 5.1.: Modules and libraries with their dependencies

As it is shown, there are 17 different modules respectively libraries, with dif-ferent dependencies according to their specification. This can easily lead to

86


an unmanageable complexity. For reducing this complexity, the frameworkRequreJS is used. “RequireJS is a JavaScript file and module loader”110, whichuses the Asynchronous Module Definition (AMD) API for JavaScript. Thisspecifies a way on how to define modules, their dependencies and how theycan be asynchronously loaded111. Such a loaded module is not within theglobal namespace as it would be the case when using the normal script tags,for example. Instead, it is a scoped object that can define its dependencies anduse them via a handle. A module itself can also offer methods by returningthem within the define-function. Another positive effect of modules beingnot in the global namespace is that different versions of a library or a modulecan be loaded within the same page without conflicts.Listing 5.5 shows an extract of the emberUImodule to show how a module is de-fined. This module is the implementation of the UserInterface-component.

Listing 5.5: Exemplary definition of the emberUI module1 define( [ "jquery", "shareJs_tinymce", "emberjs", /*...*/ "sharejs" ],2 function($, shareJsPlugin) {3 //...4 return {5 removeUser : function(user) {6 CollaborativeEditor.userController .removeUser(user);7 },8 //...9 });

A module definition always starts with the define-function. Its first argumentis an array of strings that defines the modules, the new one depends on. Each ofthese strings uniquely identifies a module which is described later in detail. Thesecond argument is the so called “definition-function” that will be automaticallyinvoked to define the module after all dependencies are loaded. The definitionfunction gets passed the dependencies in the same order, as they were definedin the array before. The names of these parameters are now the handlesthat allow the access to them within the new module. In line two, only twoparameters are passed, as they are directly accessed within the definition-function. The other modules defined as dependencies are simply loaded. Thelast step within the definition function is the returning of an object that makesdata and methods available for other modules. Line five shows for example110[Bu11b]111[Bu12]

87


the removeUser-function, which is one method within this object. It changesthe model within the emberUI-module and is later called by the IO componentif a user leaves the system.To use this modular ecosystem an additional JavaScript file needs to be addedthat manages and configures all modules. In the collaborative editor this filecalled main.js. In fact, this is the only JavaScript file despite of the RequireJSlibrary that is loaded via a script tag within the main html file. Listing 5.6shows an extract out of this file.

Listing 5.6: RequireJS configuration1 require . config({2 paths: {3 //...4 jquery_ui: ’../tagit/jquery-ui-1.8.24.custom.min’,5 shareJs_tinymce: ’shareJs_tinymce’,6 emberUI: ’emberUI’,7 io : ’io’,8 chat: ’chat’9 },

10

11 shim: {12 ’sharejs’: {13 deps: [’bcsocket’],14 },15 //...16 ’emberjs’: {17 deps: [’handlebars’]18 }19 }20 });21

22 require (["jquery", "emberUI", "io", "chat"], function($, ui) {23 $(function() {24 ui . init () ;25 //...26 });27 });

All libraries and modules reside in an own file. At first, all these modules andlibraries get a string id assigned which is shown from line four to line eight.All those referenced files are JavaScript files, but as RequireJS expects thatfiletype anyway, the extension is omitted.

88


Unfortunately, not all modules are defined the way described in Listing 5.5.In fact most files are not, especially third party libraries. Therefore, there isno dependency declaration available for them and they would be loaded in arandom order which would lead to an undefined behavior where the app wouldsometimes work if the order was correct, but most of the times not. Still, towork with them the dependency declaration can be caught up by using “shimconfig” which is done within the listing from line 11 to line 18. ember.js forexample depends on handlebars, which is therefore always loaded first.All the dependencies presented in Figure 5.1 are modeled via the above twoways. The self-written modules were already written the AMD-way, all otherlibrary dependencies are configure via shim.In line 22, the require method is invoked. Here the main app logic starts. Itloads the four modules described within the string array and in the backgroundall needed dependencies. In the function, passed as the second argument, theui.init()-function is called. From now on, the user interface is visible for theuser.

5.2.2. User Interface with Twitter Bootstrap and

Ember.js

The layout of the user interface is built with Twitter Bootstrap, a front-endframework for web development112. To meet the requirements stated in Sec-tion 4.4.2.1, the so called “Fluid layout” was used which is on the one handstructured as defined and on the other hand a responsive layout that scalesautomatically depending on the screen size. The collaborative editor addition-ally uses the lot of components of Twitter Bootstrap like buttons, dropdownsor its tooltip functionalities. In the end, Twitter provides a lot of CSS andJavaScript that was included into the collaborative editor for having a nicelooking user interface. Furthermore, the user interface of Tricia will use Twit-ter Bootstrap in future which enables an easy adjustment of the user interfaceof the collaborative editor to fit into the design of Tricia.

As presented as part of the realtime architecture in Section 4.2 and in thedesign section of the collaborative editor 4.4.2.1, the user interface componentis following the Model-View-Controller-pattern. For its implementation, the

112[Tw13]

89

framework Ember.js is used. Basically, Ember.js follows five core concepts thatsupport this pattern. The first concepts are templates. Templates describethe user interface via utilizing the Handlebars tempting language. Despiteof HTML, such a templates can contain expressions, that directly map tocontroller or model data and automatically updates them, if the respectivesources change. Furthermore they can contain so called outlets that act asplaceholders for other templates. This functionality is used for the contentarea within the collaborative editor. It shows the dashboard at the beginningand changes its view or template during the client lifecycle for displaying anoverview of documents, the editor page or the page that shows the reviews.Additionally, a template can contain views, that handles interactions.The second core concept are views that are located within a template andhandle, as already described, user events like clicks. Controllers, that are thethird core concept, are responsible for storing the application state. Theyare also often the link between the models and the templates. This meansthat they fetch data out of the model and pass it to the template directly ortranslate it to a representation, the template expects. The fourth concept arethe models, that actually store persistent state which is the data, needed bythe application. The last core concept is the router. It manages the applicationstate by mapping the URLs with the needed templates and models. It alsoupdates the URLs when the user navigates through the application and goesthrough different states113. The available states were already described inFigure 4.5.

The usage of these concepts is described via code snippets in the following.Listing 5.7 shows an extract out of the application-template.

Listing 5.7: The application-template1 <script type="text/x-handlebars" data−template−name="application">2 <div id="wrap">3 <!--Lot of Twitter Bootstrap div-tags for the top navigation bar ->4 <p class="navbar-text pull-right">Logged in as {{CollaborativeEditor.

ownIdentidy.user.name}}</p>5 <!--closing div-tags ->6

7 <div class="container-fluid">8 <div class="row-fluid">9 <div class="span3">

113cf. [Ti13a]

90

10 <div class="well sidebar-nav">11 <ul class="nav nav-list">12 <li class="nav-header">Sidebar</li>13 <li id="sb_dashboard" class="active sb">14 {{#linkTo "dashboard"}}Dashboard{{/linkTo}}15 </li>16 17 </ul>18 </div>19 {{view CollaborativeEditor.DocumentViewersView}}20 <div class="well sidebar-nav">21 <ul class="nav nav-list">22 <li class="nav-header">Users</li>23 {{#each item in CollaborativeEditor.userController.content}}24 {{#view CollaborativeEditor.OnlineUserView userBinding="item"

}}25 26 <div {{bindAttr id="item.htmlId"}} class="dropdown-menu">27 <ul>28 <li><a tabindex="-1" href="#" {{action startChat item}}>

Talk to </a></li>29 <li><a tabindex="-1" href="#"{{action prepareInvite item}}>

Invite for collaborative work</a></li>30 </ul>31 </div>32 33 {{/view}}34 {{/each}}35 </ul>36 </div>37 </div>38 <div class="span9" id="container">39 {{outlet}}40 </div>41 42 </script>

The application template is the main template. When Ember.js is loaded ini-tially, it looks for this template automatically and shows it. First of all, thetemplate is embedded in a script tag with the type “text/x-handlebars” whichshows, that the handlebars tempting language is used. There are a lot of divtags for using Twitter Bootstrap. Most important are the span-classes thatdescribe different elements within the user interface. span3 (line nine) for ex-

91


ample defines the content of the left frame of the page, where the navigationand the list of online users is embedded. span9 (line 38) is the main areawhere the changing content is displayed. Within this template there is a lotusage of handlebars tags. In line four, there is an expression that directlylinks to the model, which contains the user identity. The link refers to thename, which means that this handlebar expression is automatically replacedby the value behind the name attribute of the model. In line 14, there is thelinkTo helper shown. It gets replaced by a <a>- tag. The linkTo relates todocument states, so if the link “Dashboard” is clicked, the router transformsthe application state to the state “dashboard”. In line 19, another view getsembedded, the DocumentViewersView, where all document viewers are shown.This relates to another template file which is included on demand. Line 23realizes a loop that iterates through all online users. Afterwards, within line24, a new view is created, which ends in line 33. This view is responsible forshowing one user at the very left, including its name, image and current activ-ity. It also realizes the functionality of chatting and inviting, which is shownin line 28 and 29. The action-tags are also replaced by <a>- tags, but theycall a method of the application controller. If a user clicks on the link, imple-mented within line 28, the operation startChat of the application controlleris called. The current item, which is the user, gets passed as argument. Asalready mentioned, this whole view is embedded into a loop through all users,which enables the described behavior for all users. Ember.js takes care of theupdating automatically, which means, that if a new user joins, or if one leaves,which changes the model of the userController, the view gets automaticallyupdated. In line 39, the {{outlet}}-tag is shown, which is a placeholder forother template files that get loaded into the template at this position.

Figure 5.2 shows the start page of the collaborative editor. It is directly gen-erated out of the application-template, described above, with the dashboardincluded into the outlet. At the left, the two links “Dashboard” and “Docu-ments” can be seen. These are shown within the template in Listing 5.7 inline 14 and 16. At the right top, the name of the currently logged in useris shown. This is stored within the “CollaborativeEditor.ownIdentidy”-object.The template directly refers to this model, which is shown within the templatein line four. At the left, below the links, there is the list for all currently onlinecollaborators with the headline “Users”. As it can be seen, there is only oneother user currently online.

92


Figure 5.2.: The Collaborative Editor Start Page

In the template in Listing 5.7, this is realized from line 23 to line 34 within theloop. Furthermore, the Figure shows the dashboard, which is the first templateloaded into the outlet after the start. It shows the number of documents andnumber of online users. The number in the middle is currently not active.

As already described, the outlet is the placeholder for the dynamic contentarea. It gets automatically replaced by other templates, fitting to the currentapplication state. The managing of states is the responsibility of the router,whereas the respective routes of the router are shown in Listing 5.8. Theyalso correlate to the UML Sate Diagram 4.5, presented in the client designsection.

Listing 5.8: Router states1 CollaborativeEditor.Router.map(function() {2 this.route(’dashboard’);3 this.resource(’documents’);4 this.resource(’editor’ , { path: ’/editor/:documentName’ });5 this.resource(’review’ , { path: ’/review/:documentName’ });6 });

If a user starts the collaborative editor, she gets automatically redirected to thedashboard state. Ember.js automatically puts the template called “dashboard”into the outlet, which is directly related to the DashboardController. It alsoautomatically matches the URL /dashboard to this state, if nothing else is

93


specified.If a post processing needs to be done, before a state is entered, a resourcecan be used, which can be seen from line three to line five. An example isthe review resource shown in line five. Its path is “/review/:documentName”,whereas the part after the second slash is a dynamic segment, which is used forthe real document name. A proper URL for the review page of the document“HelloWorld” would therefore be “/review/HelloWorld”. Listing 5.9 shows theresource code for review-route.

Listing 5.9: Review Route with post processing1 CollaborativeEditor.ReviewRoute = Ember.Route.extend({2 model: function(params) {3 return params.documentName;4 },5 setupController: function(controller, documentName) {6 controller . set(’documentName’, documentName);7 }8 });

It contains two important methods, whereas Ember.js calls them hooks, asthey can be used for the preprocessing. The model-hook is used to parse theURL into a fitting model114. The only part which is needed is the documentname, so this is filtered out of the URL within line three and gets returned.The second hook setupController, can be used to set some attributes of thecontroller. The respective controller, which is the ReviewController in thiscase, gets passed as argument automatically. The second argument is the valuereturned by the model-hook. In line six, the attribute “documentName” of thecontroller is set to the value, returned by the model-hook, that parsed the nameout of the URL. After the routing was done, the controller gets automaticallyloaded. This one now has resource to the dynamic document name, as it wasset by the router within the preprocessing. All other resources are quite similarcompared to the presented one.

Controllers are another major concept of the implementation of the user inter-face. To illustrate the usage with Ember.js, Listing 5.10 shows an extract outof the ReviewController.

114cf. [Ti13b]

94


Listing 5.10: Extract out of the Review Controller1 CollaborativeEditor.ReviewController = Ember.Controller.extend({2 documentName : "",3 setReviewVersion : function(reviewNumber) {4 //Build the requested version of the review by starting with the first

document version and applying the operations continuously5 }6 });

To create a controller with Ember.js, the new one has to extend the Ember.Con-troller-class, which is shown in line one. Afterwards, special attributes andmethods can be defined within the controller to make them usable for the othercomponents. The documentName-attribute was already set by the router, pre-sented in Listing 5.9. According to the design section of the client, the Review-Controller additionally has a method called setReviewVersion, to set thecurrent review version. This one is shown in line three.

The last important concept are the views. As an example, Listing 5.11 showsan extract out of the review-view implementation.

Listing 5.11: Extract out of the review-view1 CollaborativeEditor.ReviewView = Ember.View.extend({2 templateName : "review",3 didInsertElement : function() {4 var controller = this.get(’controller’);5 //Set the document name from the controller6 //Make use of the controller-function to set the current version of the

review7 }8 });

For creating a Ember.js view, it has to extend the Ember.View-class, which isshown in line one within the listing. Every view can manually set its templatewhich can be seen here within line two. In this case, it is not necessary, asthey would be automatically matched because of their names. Also the viewprovides hooks. Often used within the collaborative editors views are thedidInsertElement-hooks, that are called after the template was inserted intothe DOM or the template was re-rendered115. In this case, the function isused to insert the document name from the controller into the template and

115cf. [Ti13b]

95


makes use of the controllers functionality of setting the chosen version of thereview.

All the controllers, views and templates are implemented similar to the abovepresented ones, according to the design decisions, made within Section 4.4.

5.2.3. Collaborative Editor Details

The integration of an editor and the enabling of working collaboratively ona document is a major part of this Thesis. The principle technique which isused to work collaboratively is operational transformation which was presentedwithin Section 2.1.2. Also the design decisions were already introduced inSection 4.4. This section focuses on the respective implementation.

5.2.3.1. From TinyMCE to Operations

One requirement for the development of the collaborative editor was the in-tegration of TinyMCE, a web-based “what-you-see-is-what-you-get” (WYSI-WYG) editor, implemented in JavaScript116. Furthermore, it was chosen touse the Node.js library share.js as operational transformation framework. Tomake them work together, the module ShareJS_TinyMCE was developed, whichis presented in detail in the following. Share.js’ client representation of the doc-ument is a Document-object117. It is a handle to the real document that residesat the server. The used methods of the document-object are presented withinTable 5.1.

Method Signature Description

getText() Get the textual content of the documentinsert() pos, text, [func-

tion(error, appliedOp)...]

Submit an insert operation, whereas“text” is inserted at position “pos”. Thecallback method is called, if the serveracknowledged the operation. It further-more provides error messages, if an erroroccurred.

116cf. [Mo12]117cf. [Ge12a]

96


del() pos, length, [func-tion(error, appliedOp)...]

Submit a delete operation, wheres adeletion from position “pos” for “length”characters was done. The callbackmethod is called, if the server acknowl-edged the operation. It furthermore pro-vides error messages, if an error occurred

Table 5.1.: Methods of the Share.js document-object

These methods build the basis for working with share.js. If the self-writtenmodule ShareJS_TinyMCE is loaded, the Share.js document-class gets extendedby a function called attach_tinymce. Its primary task is to connect a Share.jsdocument with a TinyMCE editor-instance. This function takes the DOM-element name of the TinyMCE instance as parameter. Additionally the emailaddress of the user and a function, that returns the color of her. The attach_-tinymce-function has the following two major tasks:

1. If a user with the current role as writer changes the content of a docu-ment within TinyMCE, the function first has to detect this change andafterwards find the changes to deliver a proper operation to the servervia the share.js document-object. Additionally, the current cursor posi-tion has to be submitted properly on every change to make it visible forthe other readers, too.

2. The readers continuously receive operations that are distributed by theserver. Therefore the second major task of this function is the listeningfor these changes and the making of a proper adjustment of the contentof TinyMCE.

The implementation of both functionalities follows the design, presented inSection 4.4.2.3. As the collaborative editor has an event-driven nature, it isalso built with the usage of events.To recognize a change within TinyMCE, meaning, that the writer inserted ordeleted something, the implementation uses two events: KeyUp and Click,which are attached to the TinyMCE instance. The KeyUp- and Click-eventwere chosen, as they catch all cursor movement on the one side, on the other

97


side also recognize almost every insertion or deletion of a character. Unfortu-nately, elements that are included via the TinyMCE-buttons are not recognizedby these events. These are for example tables or images. If these elements getinserted via the TinyMCE-buttons, they are only distributed after anotherKeyUp- or Click-event occurred. An Exemplary extract of the code for theKeyUp-event can be seen in Listing 5.12.

Listing 5.12: KeyUp-listener for recognising changes1 tinyMCE.get(elementName).onKeyUp.add(function(e) {2 setCurrentCursorPosition(doUpdate);3 });

In line one, the attaching of the listener to the KeyUp-event can be seen, whereasthe code for the Click-event is similar. The DOM-element name was passedto the attach_tinymce-function as parameter and the get-function returnsthe respective TinyMCE instance. If it emits the KeyUp-event, the anonymousfunction is called. Within, a function is called that sets the current cursorposition into the document, whereas the doUpdate-function is given as param-eter. In this example, the order of execution is important: first, the cursorposition has to be set, then, the doUpdate-function must be called. To makethis sure, the pattern of using callback-functions is quite typical for event-drivelanguages like JavaScript. This means, that the doUpdate-function is calledwithin the setCurrentCursorPosition-function at the needed place.The setCurrentCursorPosition-function itself inserts a special span elementinto the editor at the current position of the cursor. This span is styled as acolored cursor, which enables the user to see her own cursor in her own color.The embedding directly into the document also enables the distribution of thecursor to all other readers. So, they can follow live, what the writer is editingcurrently. If the role of the writer switches, the cursor must be positionedcompletely new and its color must be changed, according to the new writer’scolor.

Listing 5.13 shows the respective span element, that is embedded into thedocument and represents the writer’s cursor.

Listing 5.13: Span-Element for user-specific cursors1 <span id="cursor_’ + authorId + ’"></span>’)

98


The respective authorId is built out of the email address of the user, whereascharacters, that are not allowed as an ID for HTML-elements are replaced likethe @-character.

After the insertion of the cursor at the right position, the doUpdate-functionis invoked. Its purpose is to compare the document, which is currently withinthe editor with the document, that is currently at the server. As this one isonly triggered, if either the KeyUp or the Click event was emitted, there is adifference in any case, at least a different cursor position.

The compare algorithm does a character-wise comparison of both documentsfrom the beginning and from the end of both documents. This results in twonumbers. The first one indicates the number of characters from the beginning,that are equal in both documents. The second one indicates the number ofequal characters from the end of both documents. If the sum of these valuesis different to the length of the servers document a deletion was done. If thesum differs to the length of the new document an insertion was done.The following example will explain the algorithm. The initial situation ofall clients and the server version is, that the document contains the string“HelloWorld”. One user now deletes the character “e”, resulting in the string“HlloWorld”, therefore, the version within her editor differs now from the serverone. The result of comparing these versions are two numbers. From the be-ginning, there is one character equal, from the end, there are eight ones. Thesum of theses values is nine, which differs from the length of the old document,which was ten, so a deletion was done. At the same time, it is equal to thelength of new document, therefore, there is no insertion. Lets assume, the userinserted a character like an underscore, resulting in the string “Hello_World”.The number that counts the same characters from the beginning is now five,the number that counts from the end is five, too. The sum of those is ten,which is equal to the servers’ document length, but different, to the editors’one, so an insertion was done.This proceeding enables the client to decide for each change, whether an inser-tion or a deletion was done and to submit the proper operations to the server.The algorithms complexity is O(n) and it was developed by Joseph Gentle,published at [Ge13].

99


In addition to the functions the document-object of share.js offers, it also emitsevents. The two events that are used by the collaborative editor are insert

and delete , which are emitted if a new operation was done at the server. Inaddition, they provide the respective position and the text, that was addedor deleted. With their help, the second functionality of the attach_tinymce

module is implemented.For a proper handling of these events, a special class called OperationWrapper

was developed whose class diagram is shown in Figure 5.3.

Figure 5.3.: The OperationWrapper class

The insert-event, emitted by the share.js document-object provides the newtext and its position. It is directly forwarded to the OperationWrappers func-tion performInsert(). The deletion is passed to queueDeletion(). TheOperationWrapper then manages the application of the operations to the con-tent of TinyMCE. As the name of the function already implies, the deletionsare queued, whereas insertions are applied immediately. The reason for thisis TinyMCE’s internal behavior of automatically normalizing its underlyingHTML as this one is used by the client, to apply the incoming operations.A single change of the writer can lead to multiple insertions or deletions. Ifthese changes would be applied directly it can lead to a malformed HTMLwhich would then be normalized by TinyMCE. Afterwards, different userswould have different HTML code basis depending on their current role of readeror writer. The relative positions would not be the same anymore which wouldmake the application of OT impossible. Therefore it is important to apply op-erations that result out of one change together before setting it into TinyMCE.To reach this behavior, the OperationWrapper first loads the HTML contentout of TinyMCE into the content-attribute. If only an insertion needs to be

100


done, the operation is applied immediately to content which is then set intoTinyMCE. If a deletion arrives it might belongs to only one change with a corre-sponding insertion. Therefore, the deletion is queued. If no operations arriveswithin a certain timeframe, it gets applied, too. If another insertion comes in,all deletions are applied first and afterwards the insertion. All these changesare done on the content-attribute first, before setting it into TinyMCE.This proceeding assures, that each collaborator always has the the same doc-ument as every other.

5.2.3.2. The Editor in Action

Figure 5.4 shows a screenshot of the editor.

Figure 5.4.: The Editor in Action

The document “Pentasys” is currently opened and there are two writers work-ing collaboratively. At the left within “Viewers in Pentasys”, all other usersare shown, that have currently the same document open. If the current writerleaves the document via the back-button, another writer is chosen automat-ically. So, the collaborators are “Sascha Roth”, who is currently logged in at

101


the client shown in the screenshot, the other is “Tobias Höfler”. As it is shown,“Sascha Roth” is currently the writer, which means also, that “Tobias Höfler” iscurrently set as reader. This can be changed via the drop down menu, shownin the middle at the right. At the bottom, TinyMCE is shown with all itsmenu bars to support rich text editing. The tag-bar in the middle enables theusers to add and removes tags. These ones are distributed automatically toall other collaborators, looking at the document.

5.2.4. Implementation of the Editor Overview

Larger documents often do not fit into the editor without the need to scroll.This leads to a loosing orientation and overview for the readers. On the onehand they cannot realize the document as a whole, on the other hand theycannot follow the cursor of the writer anymore, as this one may be out oftheir current viewport. To address this issue, the editor overview provides anoverview of the whole document including the images of the users to marktheir current positions within the document.To implement this feature an iFrame is created directly under the editor whichcontains a copy of the document within the editor. It gets automaticallyupdated on every change. For providing the overview-character, it has 40% ofthe size as it would normally has. Listing 5.14 shows the respective CSS forreaching this.

Listing 5.14: CSS for the overview1 #documentOverview {2 width: 240px;3 float : left ;4 transform: scale (0.4, 0.4) ;5 −ms−transform: scale(0.4, 0.4); /∗ IE 9 ∗/6 −moz−transform: scale(0.4, 0.4); /∗ Firefox ∗/7 −webkit−transform: scale(0.4, 0.4); /∗ Safari and Chrome ∗/8 −o−transform: scale(0.4, 0.4) ; /∗ Opera ∗/9 }

The major part of the CSS is the resizing, presented from line four to lineeight. It shrinks to whole iFrame to 40% of the normal size. As it can be seen,there are browser specific statements needed for the realization.Furthermore, the original cursor of the writer is replaced by her image, as the

102


normal cursor would not be visible anymore clearly. To implement this, thewhole document is processed each time an update is done. It is scanned forthe span-element that belongs to the cursor of the writer. With the help ofthe ID of the cursor element, the former cursor position can be mapped to theuser images and replaced by img-elements that include the image of the user.Figure 5.5 shows an overview of an exemplary document.

Figure 5.5.: Exemplary Editor Overview

It is shown, that the cursor is replaced by the image of the writer. The upperleft corner of the image is positioned at the former cursor position.

5.3. Integration into Tricia

Tricia is a major component of the collaborative editor. Although from anarchitectural point of view it resides at the server-side it is described in aseparate section, as it also makes important pre-processing tasks for a properclient-code delivery and as it is intentionally separated from the self-writtenserver. Tricia realizes multiple functionalities. First it does the authenticationand authorization and delivers the client-code if the client is registered atTricia. Furthermore, it provides user information and the documents that willbe edited within the collaborative editor. The implementations of these tasksare described in the following.

For meeting the requirements of the collaborative editor, Tricia’s functionalitiesare extended by three new so-called “Handlers”. Handlers are mapped to asingle URL, depending on the class-name of the respective Handler and thepackage, the classes are placed in. Such a handler can return special replies,whereas SimplePage and JsonAnswerStation is used. The first one returns,as the name already implies, a simple page and the second one returns a JSONformatted object. The typical workflow of the interaction of a user with Triciais shown in Figure 5.6.

103


Figure 5.6.: Interaction workflow with Tricia

The CollaborationHandler is mapped to the URL “/node/collaboration” asit is within the package “node” and as the name begins with “Collaboration”.Its first task is to check, whether a user is logged in in Tricia. If not, she getsredirected to “/node/reject”, which is managed by the RejectHandler thatshows a page with an information for the user and the possibility to go to theTricia login page. Both handlers return a SimplePage that has a underlyingtemplate file which is the page that gets delivered to the user. The templatefile of the RejectHandler is a simple html page that is delivered to the user,whereas the template file of the CollaborationHandler is more complex. Ithas special placeholders that get replaced by the handler to construct a targethtml-file before it is delivered to the user. These placeholders stand for the CSSand JavaScript imports of the html-file. In fact, this HTML and the JavaScriptfiles contain the whole client code. Additionally, the user information of thecurrently logged in one gets included. These are the name, the email addressof the user and the URL to the image, the user provided in her Tricia profile.All addressable pages, CSS and JavaScript libraries in Tricia have a special

104


cache breaker string within the URL. This one gets replaced at last within thetemplate file. Now, the page is ready to get delivered to the client.

In addition, there is AllDocumentsHandler. It returns all the documentscurrently available in Tricia in form of a JSON response. To do so it has theJsonAnswerStation return type, which automatically translates the documentobjects of Tricia to JSON. This is accessible via “/node/allDocuments”.

5.4. Prototypical Implementation of the Server

The server part of the collaborative editor is implemented with Node.js, whichwas introduced within Section 2.4. This proceeds with the event-driven na-ture of the whole system also at the server-side. Within this section, the serverimplementation is described in detail. Section 5.4.1 describes the Implementa-tion of each module in detail, including the used third-party libraries and theinterfaces exposed for other modules.

5.4.1. Implementation of the Server Components

The server consists of different components as described on a high-level in Sec-tion 4.5. These components are partially based on third party libraries or arecompletely written in own JavaScript code. For giving a first impression aboutthe different parts of the prototype and the usage of libraries and technologies,Figure 5.7 shows again the different server components, now with the focuson the involvement of major third party libraries and technologies. Here, onecomponent, the CommunicationManager, was added. It is fully realized withsocket.io and manages the communication with the clients. The introductionof this new modules leads to clearer responsibilities for the implementation.

The components App, TriciaConnector, DocumentManager, ReviewManagerand ColorManager are, beside of the usage of the database client, completelyself-written. The central App-component integrates all parts and makes use offunctionalities of socket.io for enabling the bidirectional communication withthe client(s). The CommunicationManager itself represents the functionalitiesof socket.io. The ConcurrentEditing-component is realized by share.js. TheDatabase-component is realized with Redis.

105


Figure 5.7.: Server Components with major third-party libraries

In the following, all parts are described in detail including the reasons for usingthe libraries respectively technologies.

5.4.1.1. The App Component

The App-component is the central part of the server-side of the collaborativeeditor. Listing 5.15 shows the first ten lines of the app component, that importall needed modules.

106


Listing 5.15: Includes Modules1 var http = require(’http’);2 var express = require(’express’);3 var io = require(’socket.io’);4 var sharejs = require(’share’).server;5 var redis = require("redis");6

7 var triciaConnector = require(’./triciaConnector.js’);8 var documentManager = require(’./documentManager.js’);9 var colorManager = require(’./colorManager.js’);

10 var reviewManager = require(’./reviewManager.js’);

The “http” module within line one is the Node.js core module for providinga HTTP server. It builds the basis for further modules that need to commu-nicate with the client(s). The following four modules were installed into thenode_modules folder via the node package manager NPM. Express is a special“web application framework for node” 118. It is needed to act as a requestlistener for Node’s HTTP server119 which means, that incoming requests areforwarded to express. This again is needed by share.js and socket.io. Bothlibraries are attached to this express request listener, to listen for special re-quests addressed to them. This is the only reason why express is needed. The“redis”-module is the client library for the Redis database. The last four lineswithin Listing 5.15 include the self-written modules, that are presented in thesubsequent sections.

After the import of all needed modules, the integration of the request lis-teners and the start of the HTTP-server, the App-component initiates theTriciaConnector to fetch all documents from Tricia and to give them to theDocumentManager, that stores them.Until now, the App-component managed the initial start of the collaborativeeditor.The second task of it is to realize the bidirectional communication with socket.io.To do so, it implements listeners for all events emitted by the clients whichwere already described in Table 4.2. Furthermore is listens for the connect-and disconnect-event that get emitted if a user connects or disconnects. Theconnect-event was already described in Listing 5.1. The disconnect-eventfollows a similar proceeding the other way around. If a user is disconnected

118cf. [Lo04]119cf. [Jo13b]

107


the event “a user left” gets broadcasted to all connected clients to inform themabout this event.As it was already described, the bidirectional connection of socket.io is multi-plexed. Listing 5.16 shows how this is implemented.

Listing 5.16: Multiplexing of the socket.io communication channel1 var chat = socketio.of(’/chat’);2 chat.on(’connection’, function (socket) {3 //Further listeners4 })5 });6 //....7 socketio . sockets .on(’connection’, function (socket) {8 //Listeners9 });

The “chat”-namespace is realized within line one. It gets addressed by append-ing “/chat” to the connection URL at the client. The default namespace, thatis realized in line seven, has no need of appending a string to the connectionURL. In line three and six, all the listeners are now implemented separately.Now, the server-side is started and initialized and ready to listen for events.From this moment, the clients are able to connect and work with the server.

5.4.1.2. The Concurrent Editing Component

The concurrent editing component is fully realized with share.js. Nevertheless,there are some steps to do for its integration. Listing 5.17 shows the respectivecode snippet.

The options are passed to share.js via an object which is defined from line oneto line ten. Line two defines the usage of the Redis database for storing thedocument meta data and all the operations. In line three, the cross-site accessfor BrowserChannel is enabled by setting the “Access-Control-Allow-Origin”header. This is needed, as the user originally received the data from Tricia,which runs on a different port than the Node.js server. More on this topic canbe found at [Mo13]. At last, a special authentication method is set, if a newuser connects to the server-side for getting access to the documents. Currently,there is no real authentication done, instead, this message easily provides therespective session-ID of a user an its identity, which can then be matched for

108


later usage. It is also shown, that all requests from clients are accepted via thefunction action.accept() within line eight.

Listing 5.17: Needed options for share.js1 var options = {2 db: {type: ’redis’},3 browserChannel : {cors:"*"},4 auth: function(agent, action) {5 if (action.type ==’connect’) {6 //Store the sessionID of the new user7 }8 action.accept() ;9 }

10 };11 sharerejs .attach(app, options) ;

At last, the share.js server-part is attached to express.js-server that is storedwithin the app-variable. The respective options described below are passedas parameter. From now on, the clients can use the share.js backend to workcollaboratively on a document.

5.4.1.3. Database with Redis

There is little information needed to be stored persistently at the collaborativeeditor. To do so, the key-value store Redis120 was chosen. It keeps all data inthe RAM and periodically saves it to disk, which offers high performance andpersistency at the same time. As there is only little data that need to be saved,the data probably won’t exceed the ram size, which leads to a predictable highperformance121. At last, there is no complex relational schema needed and akey-value store fits better to this scenario.

Although, there is no complex schema, a simple hierarchy is built with thekeys, to get all needed data comfortably. Given a concrete document namekeys are built as shown in Listing 5.18.

119cf. [Ge12d]120cf. [VM03]121cf. [Wa11]

109


Listing 5.18: Key schema of the key-value store1 "docs:" + documentName + ":lastModified"2 "docs:" + documentName + ":tags"3 "ShareJS:ops:" + documentName4 "ShareJS:doc:" + documentName

Line one presents the key for the date of the last modification for the documentwith the name “documentName”, line two the respective tags. The modificationdate is a normal number value whereas the value for the tags is a list. Line threeand four are keys created and managed by share.js and keep the document-meta information and the respective operations, that were submitted by theusers. For getting a list of all documents and for building the needed keys,there is a set called docs:all that keeps all document names. Another setaddressed by the key availableTags keeps all tags that were used in the past,which are used for the auto-complete functionality at the client-side.

5.4.1.4. Document Manager

Figure 5.8.: The DocumentManager

The DocumentManager realises multiple func-tionalities related to the management of doc-uments. Figure 5.8 shows the respectiveclass diagram. In general, all the presentedmethods access the database and persis-tently store information or read them. Theabove two ones are responsible to read andwrite tags, belonging to documents. Thethird and fourth method enables the server-side, to read or persistently write documents.importDocument is a special method for theTriciaConnector. It accepts as parameter aJSON-object that was created by Tricia for

delivering all available documents. This method translates Tricia’s representa-tion of documents into the representation, the collaborative editor uses. Thelast method getAllDocumentsMetaData is needed for distributing the meta-data of the documents to newly connected clients. To do so, it gets two func-tions passed as arguments. The first one broadcasts one single doc to the

110


clients by emitting the ’newDoc’ event. The second one is a callback-functionthat is called, if all documents are sent.

5.4.1.5. Tricia Connector

The TriciaConnector realizes the connection to Tricia. At this stage of devel-opment, it fetches all documents within Tricia right after the start of the collab-orative editor. For its implementation, it makes use of the AllDocumentHandlerof Tricia, described in Section 5.3, that returns all available documents withinTricia in the JSON Format. Therefore, the TriciaConnector just needs tomake a call to /node/allDocuments, parses the textual JSON response tobuild JavaScript objects and forwards them to the DocumentManager, de-scribed in Section 5.4.1.5. The respective code to do so can be seen in Listing5.19.

Listing 5.19: Access Tricia to fetch all documents1 var requestHeader = {2 host: ’localhost’,3 port: 8084,4 method: ’GET’,5 path : ’/node/allDocuments’6 }7

8 http.request(requestHeader, function(res) {9 res .setEncoding(’utf8’);

10 res .on(’data’, function (chunk) {11 callback(JSON.parse(chunk).pages);12 });13 }).end();

Line one to six build an object that represents the header for the requestthat will be done. It specifies the target host, port, HTTP-method and URL.Afterwards, a normal HTTP-request is done, including the currently createdheader-object and a anonymous callback function that is called, right after thedata is available with the response as parameter. In line ten, a listener forthe “data-event” is registered, that will be called if the response-body of theHTTP-request arrives. This gets parsed to a JSON-object and passed to the

121cf. [Ge12d]

111


callback-function, which is a function of the DocumentManager to import thenewly arrived documents.

5.4.1.6. Review Manager

The ReviewManager is responsible for creating reviews on demand. To do so,it exposes the one method getReview(docName, cb) whereas docName is thename of the document, the review is created for. cb is the callback functionthat is called with the review as parameter.For creating a review, the method reads all operations for the respective doc-ument out of the database and groups them by the users into an array. Thisone again is put into another array, that has one field for each user, therefore,the index of this field is exactly the version, the user is able to choose at theclient. The respective document is built afterwards at the client out of thetransmitted operations, depending on the chosen version.

5.4.1.7. Color Manager

The ColorManager exposes three functions: getColorPalette(), getColor(name) and changeColor(name, color). The first one returns the colorpalette in form of an array of valid color values. These ones are readableby the “Spectrum”-library used by the client for choosing colors. The secondmethod defines a unique color for each user initially, whereas name is the re-spective name of the user. The last method is used, if a user wants to chooseher color, whereas the name of the user and the chosen color is passed asparameter.

5.5. Conclusion

This chapter presented a prototypical implementation of a collaborative edi-tor. It followed the design decisions, made in Chapter 4 and was realized withJavaScript at the client- and the server-side.The client-side was developed, following the Model-View-Controller patternwith the Ember.js framework. Its core concepts of models, views, controllers,

112


templates and the router supported the implementation of the realtime ar-chitecture. All changes, done to the models, are automatically propagated tothe views, which makes the application of received events easy and directlyvisible to the user. Furthermore, it made the integration of Twitter Bootstrapstraightforward. Nevertheless, from a developer perspective, the working withEmber.js was not comfortable. Its documentation is only rudimentary andits API totally changed during the development of the collaborative editor,including fundamental concepts.When developing a web application with JavaScript, there are commonly alot of third-party libraries included for the realization of special tasks. Thisleads to a lot of dependencies between those libraries, which becomes moreand more complex with an increasing number of libraries. The framework Re-quireJS provided an elegant and efficient way, to manage all these libraries. Itoffers the building of modules and definition of the respective dependencies ina comfortable way. Additionally, it is able to include libraries, that were notintentionally made for the usage with RequireJS.The editor component of the collaborative editor tool was realized with Tiny-MCE. It offers a wide variety of functionalities that enable rich text editing. Toenable realtime collaboration, all changes to a document done by one writer,are automatically propagated to other users that currently look at the samedocument. To implement this feature, an own module was developed thatbuilds a bridge between TinyMCE and the server. To access the content withinTinyMCE, it provides its own API. It is well-documented and has a rich setof features. It turned out, that when using advanced features via TinyMCE’sAPI, there is still some browser specific behavior, which complicates the de-velopment of the client-side. This can also be seen for the implementationof the editor overview. It displays the whole document in a smaller area, toprovide an overview of the document and its current changes to the user. Itsimplementation needed specific definitions, for each major browser.The client is delivered initially by Tricia. This situation made it possible, tomake use of features of it, like the user management, authorization and au-thentication. Tricia is a complex application and it needs some induction, todevelop with it.

The server was fully developed with Node.js. Its event-driven nature sup-ported the implementation of the realtime architecture. Node.js’ rich set ofcore functionalities made the implementation of the server-side comfortable

113


and straightforward. For the realization of the collaborative editor the widevariety of different packages was very useful. With socket.io, Node.js providesa powerful way for distributing events to connected clients. It abstracts theunderlying technologies, which makes it comfortable to use. Share.js, the sec-ond major Node.js library that was used, also provides rich set of features forcollaborative editing, that was used for implementing the editor.During the implementation, one major library needed to be replaced as it wasnot supported anymore by their developers. Therefore, the selection of thirdparty libraries need to be done wisely. It is also important to realize, that a lotof libraries are developed by single persons in their private time. This makesthem less usable in an enterprise environment.

114

6. Enhancing Collaboration

In the recent sections collaboration was enabled via the instant distributionof events through the whole system. Furthermore, a collaborative editor waspresented, that enables users to follow the changes done by one single editorin realtime. Nevertheless, the collaboration can be enabled for more complexscenarios and models.

The prototype presented in Section 4 and Section 5 was based on operationaltransformation for having easy mechanisms for sharing changes on the docu-ment throughout the whole system and to easily save states of the document forfurther versioning. This approach works good for rich text when there is onlyone user writing at the same time. In fact, it works when there are no conflictsthat need to be resolved or, in an OT-context, that need to be transformed.The normal operational transformation algorithm presented in Section 2.1.2can enable reactive writing on a linear sequence of data, concretely plain text.It cannot be applied to structured content like HTML. Its application mightlead to unbalanced tags and therefore semantically incorrect code. [Go08]even states that “HTML makes OT (Operational Transforms) difficult if notimpossible”.

This section describes a mechanism to enable reactive writing of rich text andintroduces approaches to work collaboratively on arbitrary models. To do so,Section 6.1 describes Google Wave Operational Transformation, Section 6.2outlines a method to work collaboratively on arbitrary models.

6.1. Google Wave Operational Transformation

Google Wave allows reactive writing on rich text. Its core technology can evenbe used to collaboratively work on any structured data. To do so, Googleinvented their own concurrency control system, which is based on operational

115


transformation122 (see Section 2.1.2).In Goole Wave, a document consists of multiple items. Such an item is a startor end tag or a single character. The gaps between these items are calledpositions. Figure 6.1 shows an exemplary document with the respective itemsand positions.

Figure 6.1.: Google Wave Items123

This is a major difference to the concept presented in Section 2.1.2, where alloperations relate to single characters. In Google Wave, the reference unit foroperations are items. In Google Wave, operations additionally use annotationsthat are applied to a sequence of items. These annotations contain meta-data, which is actually used for text formatting124. A single operation inGoogle Wave consists of multiple actions or so called operation components.Therefore, an operation is not only a deletion or insertion of one characterbut instead, can change the whole document at multiple parts. The mostimportant operation components are presented in Table 6.1.

122cf. [WML10]123cf. [WML10]124cf. [WML10]

116


Operation component Description

insertCharacters Inserts the specified string at the current indexdeleteCharacters Deletes the specified string from the current

indexopenElement Creates a new XML open-tag at the current

indexdeleteOpenElement Deletes the specified XML open-tag from the

current indexcloseElement Closes the first currently-open tag at the cur-

rent indexdeleteCloseElement Deletes the XML close-tag at the current indexannotationBoundary Defines the changes to any annotations (start-

ing or ending) at the current indexretain Advances the index a specified number of items

Table 6.1.: Most important operation components in Google Wave125

An operation is applied in a sequence of operation components that relateto positions within the whole document, therefore, the sequential executionof the components is important. For example lets assume, there is the text<body>Test message</body> and we want to capitalize the ’m’. The respec-tive operation can be seen in Listing 6.1.

Listing 6.1: Exemplary Google Wave Operation1 retain(7)2 deleteCharacters(’m’)3 insertCharacters(’M’)4 retain(7)

First, the cursor is moved to the position seven. Afterwards, the character “m”gets deleted and “M” gets inserted. At last, the rest of the document, whichconsists of seven items, is kept as it is. This changes the “m” to an “M”. Itcan be seen, that an operation always covers the whole document and not justparts of it126.125cf. [Sp10]125cf. [Ge12d]126cf. [Sp10]

117


The remaining functionalities of Google Wave Operational Transformation aresimilar to these ones presented in Section 2.1.2, albeit all of them are morecomplex. The main difference between this approach and the classic approachof OT, presented in Section 2.1.2 is the reference unit of “items” instead of po-sitions within the plain text, including the new operations presented in Table6.1. This enables Google Wave OT to handle structure within a document incontrast to the classic approach. Nevertheless, this reference unit and the addi-tional operations lead to much more complex transformation algorithms127.

6.2. Collaborative Editing of arbitrary Models

It was shown, that the Google Wave Operational Transformation can enablereactive writing on rich text. Nevertheless, there are more complex modelsthan formatted text where this algorithm does not meet the requirements forrealtime collaboration. If there are for example two persons working collabora-tively on the simple text “Hello World” and one decides to delete the character“d” and the other one wants to make it emphasized, there is a conflict Opera-tional Transformation cannot resolve via transformation. When applying OTin general, the result might be, depending on the concrete algorithm, “HelloWorl”. So, the last character was deleted. This can be seen as acceptable fortext, as at the one side, this was the intention of one editor anyway and onthe other side, the previous state can be easily recovered, if the deletion wasnot the intention of the whole group of concurrent editors. Nevertheless, theseassumptions may not apply for any complex model.

[Br09] analyzed conflict resolution for models related to model driven engi-neering. In this context, the models are used for automatic code generation.Conflict resolution methods are an important step towards reactive writing asthey build its basis. Joseph Gentle, the developer of share.js which is usedwithin the collaborative editor prototype said for reason, that “OperationalTransformation is like realtime git”128. [Br09] stated, that standard versioncontrol systems, just as Git, are not sufficient for models. They normally workvia text comparison. If they are applied to the textual representation of amodel, important information get lost, which makes them no valuable option

127cf. [Sp10]128cf. [Ge11]

118


for models. Therefore, special version control systems for specific models hasbeen developed, whereas all follow the approach, that in case of a conflict, oneperson has to merge the two versions manually to resolve the conflict.129

This can be problematic as the one person, doing the conflict resolution, mightnot reflect the intention of the whole team, which may leads to a wrong resultor even to a potential risk of losing important data. In fact, there might beoverlapping intentions through the whole collaborators130. Furthermore, espe-cially in an early-phase of a project, there is no common understanding aboutthe system, yet, which leads to different views of different collaborators131.

To solve this problem, [Wi11] proposed a conflict-tolerant method to mergedifferent versions of models. They especially took into account, that developersdo not want to interrupt their work for manual conflict resolution. Instead,they want to submit their changes immediately and take care of the resolvinglater. The proposed approach therefore enables the developers to submit theirchanges at any time, even if there are conflicting states. Furthermore, it doesnot force the developers to resolve the conflict immediately. Instead, conflictsgets annotated, which represents a marker for later resolution, which is doneduring the consolidation phase.During a consolidation phase, all conflicts within the repository are tried tobe resolved collaboratively to get a common stable version of the model. Todo so, [Wi11] developed a structural model about this procedure. If there isa conflicting version, there are basically two possibilities to resolve them. Oneway is to choose one concrete version, another way is to reject all versions andto develop a new one in a collaborative way, which is then accepted. It mayalso happen, that a conflict depends on another one. This needs to be handledon the concrete example132.

As described above, conflicts arise especially in an early-project phase whenthere is no common view and understanding of the system, yet. Anotherpositive result of the collaborative consolidation is to produce this commonunderstanding of the system. Here, especially these project members has tofind a solution, that produced the conflict and therefore had a different under-standing of the system.

129cf. [Br09, p. 3]130cf. [Br09, p. 2 - 3]131cf. [Wi11, p. 2]132cf. [Wi11, p. 18, 29-31]

119


6.3. Conclusion

Google Wave Operational Transformation is a valuable way for enabling re-active writing on rich text. Albeit, this leads to complex transformation al-gorithms and therefore a high complexity. Google itself does not improve thewave project any more. Instead, they handed it over to the open-source com-munity. Now, it is an Apache project, whereas it “is still in its infancy” andthere is currently no stable version available of it133.

The approach presented in Section 6.2 is quite interesting for enabling reactivewriting on arbitrary models. If conflicts occur, that can not be automaticallyresolved, an annotation is created, whereas the conflicting versions are keptand the resolving is postponed. Nevertheless, this is still an ongoing researchtopic, which needs further research.

133cf. [Th12]

120

7. Conclusion and Outlook

The goal of this Thesis was to analyze how realtime collaborative web appli-cations can be enabled. Thereby, a special focus was on the assessment ofserver-side JavaScript for this scenario.

The survey, conducted within this Thesis showed a high satisfaction withJavaScript in general. Participants are contented with its syntax, tool sup-port and maintainability. They additionally stated, that JavaScript is veryimportant for their projects and that its general importance will rise in fu-ture. This builds a good basis for the future of both, client- and server-sideJavaScript. Node.js, the most prominent candidate of server-side JavaScript,is already widely known whereas projects that are using Node.js tend to besmaller and younger. The survey showed, that Node.js is typically used for webapplications. Furthermore, the majority of the participants confirmed Node.js’enterprise readiness.On the contrary, the selection of third-party libraries on top of Node.js mustbe deliberate. Even though, they can be easily installed with Nodes’ own pack-age manager, a big amount of libraries and frameworks is developed by singlepersons in their private time and are immature, yet. This makes them to apotential risk within projects, especially in enterprise environments.

The realtime architecture, presented within this Thesis, is a good pattern forenabling realtime collaboration in web applications. It allows an easy way ofsending events through the system and making the impact of them applicableat the client-side. As this architecture is fully event-driven, Node.js is a goodfit for implementing the respective server-side. Especially in combination withsocket.io, Node.js can enable realtime communication easily, which was shownwith the implementation of the collaborative editor prototype.

Nevertheless, there are still open topics, that need to be evaluated in furtherresearch. There were some approaches presented within this Thesis, for collab-

121

7. Conclusion and Outlook

orative editing of rich text and arbitrary models. The Google Wave Protocolis a valuable way for realizing reactive writing on rich text. Unfortunately,the algorithms behind are quite complex and would lead to an immense im-plementation effort, when it should be used in practice. Collaborative editingof arbitrary models is still an open topic. Although, the approach presentedwithin this Thesis is quite interesting for enabling collaboration, there is stilla manual merge to be done.Furthermore, the integration of the collaborative editor into Tricia can be en-hanced in future. Especially, realtime collaboration functionalities like the chator the displaying of online users could be integrated into Tricia, to enhance itscollaboration features.

122

Bibliography

[Ac13] ActiveState Software Inc.: Komodo IDE 7: The Professional IDEfor Python, PHP, Ruby and Perl | ActiveState. http://www.

activestate.com/komodo-ide. 2013. [Online; accessed 24.01.2013].

[Ad12] Adobe Systems Inc.: Adobe Flash Professional CS6. http://www.

adobe.com/de/products/flash.html. 2012. [Online; accessed12.12.2012].

[BMN10] Büchner, T.; Matthes, F.; Neubert, C.: Data model driven imple-mentation of web cooperation systems with Tricia. In Objects andDatabases. pages 70–84. Springer. 2010.

[Br09] Brosch, P.; Seidl, M.; Wieland, K.; Wimmer, M.; Langer, P.: We canwork it out: Collaborative conflict resolution in model versioning. InECSCW 2009. pages 207–214. Springer. 2009.

[Br10] Braunstein, R.: ActionScript 3.0 Bible. Wiley. 2 edition. 2010.

[Bu10] Bundesverband Informationswirtschaft, Telekommunikation und neueMedien e.V.: Studie „Connected Worlds“ - Wie Lebens- undTechnikwelten zusammenwachsen. http://www.bitkom.org/files/

documents/bitkom_connected_worlds_extranet.pdf. 2010. [On-line; accessed 10.05.2013].

[Bu11a] Bundesverband Informationswirtschaft, Telekommunikation und neueMedien e.V.: Soziale Netzwerke - Eine repräsentative Untersuchungzur Nutzung sozialer Netzwerke im Internet. http://www.bitkom.

org/files/documents/sozialenetzwerke.pdf. 2011. [Online; ac-cessed 10.05.2013].

[Bu11b] Burke, J.: RequireJS. http://requirejs.org/. 2011. [Online; ac-cessed 02.04.2013].

123

http://www.activestate.com/komodo-ide

http://www.activestate.com/komodo-ide

http://www.adobe.com/de/products/flash.html

http://www.adobe.com/de/products/flash.html

http://www.bitkom.org/files/documents/bitkom_connected_worlds_extranet.pdf

http://www.bitkom.org/files/documents/bitkom_connected_worlds_extranet.pdf

http://www.bitkom.org/files/documents/sozialenetzwerke.pdf

http://www.bitkom.org/files/documents/sozialenetzwerke.pdf

http://requirejs.org/

Bibliography

[Bu12] Burke, J.: AMD. https://github.com/amdjs/amdjs-api/wiki/

AMD. 2012. [Online; accessed 02.04.2013].

[Ch12] Chow, J.: Continuous Integration for Mobile. http://engineering.linkedin.com/testing/continuous-integration-mobile. 2012.[Online; accessed 24.01.2013].

[Cl12] Cloud9ide: Cloud9 IDE | Online IDE – Your code anywhere, anytime.https://c9.io/. 2012. [Online; accessed 09.04.2013].

[Co13] Code Together, L.: Squad: Collaborative Code Editor. https://

squadedit.com/. 2013. [Online; accessed 09.04.2013].

[Da11] Dahl, R.: Ryan Dahl - History of Node.js. http://youtu.be/

SAc0vQCC6UQ. 2011. [Online; accessed 10.05.2013].

[EB11] EBay Inc.: Announcing ql.io. http://www.ebaytechblog.com/2011/11/30/announcing-ql-io/. 2011. [Online; accessed 24.01.2013].

[EG89] Ellis, C. A.; Gibbs, S. J.: Concurrency control in groupware systems.In ACM SIGMOD Record. volume 18. pages 399–407. ACM. 1989.

[Fi12] Ficarra, M.: CoffeeScript. http://coffeescript.org/. 2012. [On-line; accessed 04.02.2012].

[Fl11] Flanagan, D.: JavaScript: The Definitive Guide: Activate Your WebPages (Definitive Guides). O’Reilly Media. 2011.

[FR11] Fernandez-Ruiz, B.: Yahoo! Announces Cocktails – Shaken, NotStirred. http://developer.yahoo.com/blogs/ydn/posts/2011/

11/yahoo-announces-cocktails-?-shaken-not-stirred/. 2011.[Online; accessed 24.01.2013].

[Fr13] Free Software Foundation Inc.: GNU Emacs. http://www.gnu.org/software/emacs/. 2013. [Online; accessed 24.01.2013].

[FRSF10] Fraternali, P.; Rossi, G.; Sánchez-Figueroa, F.: Rich Internet Ap-plications. IEEE Internet Computing. 14(3):9–12. 2010.

[Ga77] Gannon, J.: An experimental evaluation of data type conventions.Communications of the ACM. 20(8):584–595. 1977.

[Ga13] Gartner Inc.: IT Market Clock for Programming Languages, 2013.2013.

124

https://github.com/amdjs/amdjs-api/wiki/AMD

https://github.com/amdjs/amdjs-api/wiki/AMD

http://engineering.linkedin.com/testing/continuous-integration-mobile

http://engineering.linkedin.com/testing/continuous-integration-mobile

https://c9.io/

https://squadedit.com/

https://squadedit.com/

http://youtu.be/SAc0vQCC6UQ

http://youtu.be/SAc0vQCC6UQ

http://www.ebaytechblog.com/2011/11/30/announcing-ql-io/

http://www.ebaytechblog.com/2011/11/30/announcing-ql-io/

http://coffeescript.org/

http://developer.yahoo.com/blogs/ydn/posts/2011/11/yahoo-announces-cocktails-?-shaken-not-stirred/

http://developer.yahoo.com/blogs/ydn/posts/2011/11/yahoo-announces-cocktails-?-shaken-not-stirred/

http://www.gnu.org/software/emacs/

http://www.gnu.org/software/emacs/

Bibliography

[Ge11] Gentle, J.: ShareJS – Live concurrent editing in your app. http:

//sharejs.org/. 2011. [Online; accessed 21.03.2013].

[Ge12a] Gentle, J.: Client API. 2012. [Online; accessed 21.03.2013].

[Ge12b] Gentle, J.: josephg/node-browserchannel. https://github.com/

josephg/node-browserchannel. 2012. [Online; accessed 21.03.2013].

[Ge12c] Gentle, J.: JSON Client API. https://github.com/josephg/

ShareJS/wiki/JSON-Client-API. 2012. [Online; accessed23.03.2013].

[Ge12d] Gentle, J.: Wire Protocol. https://github.com/josephg/ShareJS/wiki/Wire-Protocol. 2012. [Online; accessed 21.03.2013].

[Ge13] Gentle, J.: ShareJS/src/client/textarea.coffee at master -josephgShareJS - GitHub. https://github.com/josephg/ShareJS/blob/master/src/client/textarea.coffee. 2013. [Online;accessed 05.04.2013].

[Gi13] GitHub Inc.: Top Languages. https://github.com/languages.2013. [Online; accessed 22.01.2013].

[Go08] Google Inc.: FAQ - Google Wave FederationProtobol. http://www.waveprotocol.org/faq#

TOC-What-s-the-XML-schema-for-waves-Why-isn-t-it-HTML5-.2008. [Online; accessed 18.04.2013].

[Go13] Google: Welcome to Google Apps. http://www.google.com/apps/

index1.html. 2013. [Online; accessed 11.05.2013].

[GT02] Gourley, D.; Totty, B.: HTTP: The Definitive Guide. O’Reilly Media.2002.

[Ha10a] Hanenberg, S.: An experiment about static and dynamic type systems:Doubts about the positive impact of static type systems on developmenttime. ACM Sigplan Notices. pages 22–35. 2010.

[Ha10b] Hanenberg, S.: Doubts about the positive impact of static type systemson programming tasks in single developer projects-an empirical study.ECOOP 2010–Object-Oriented Programming. pages 300–303. 2010.

125

http://sharejs.org/

http://sharejs.org/

https://github.com/josephg/node-browserchannel


https://github.com/josephg/ShareJS/wiki/JSON-Client-API

https://github.com/josephg/ShareJS/wiki/JSON-Client-API

https://github.com/josephg/ShareJS/wiki/Wire-Protocol

https://github.com/josephg/ShareJS/wiki/Wire-Protocol

https://github.com/josephg/ShareJS/blob/master/src/client/textarea.coffee

https://github.com/josephg/ShareJS/blob/master/src/client/textarea.coffee

https://github.com/languages

http://www.waveprotocol.org/faq#TOC-What-s-the-XML-schema-for-waves-Why-isn-t-it-HTML5-

http://www.waveprotocol.org/faq#TOC-What-s-the-XML-schema-for-waves-Why-isn-t-it-HTML5-

http://www.google.com/apps/index1.html

http://www.google.com/apps/index1.html

Bibliography

[HB11] HBR Labs, L.: Web Meeting and Document Sharing | ShowDocu-ment. http://www.showdocument.com/. 2011. [Online; accessed09.04.2013].

[Ho12] Holowaychuk, T.: Express - node.js web application framework. http://expressjs.com/. 2012. [Online; accessed 21.12.2012].

[in12] infoAsset AG: infoAsset : Home. http://www.infoasset.de. 2012.[Online; accessed 13.11.2012].

[Is11] Isaac Z., Schlueter: Node.js Digs Dirt - about Data-Intensive Real-Time Applications. http://video.nextconf.eu/video/1914374/

nodejs-digs-dirt-about. 2011. [Online; accessed 10.05.2013].

[Je13a] JetBrains: IntelliJ IDEA :: Features. http://www.jetbrains.com/

idea/features/index.html. 2013. [Online; accessed 14.05.2012].

[Je13b] JetBrains: The best JavaScript IDE with HTML Editor for Web de-velopment :: JetBrains WebStorm. http://www.jetbrains.com/

webstorm/. 2013. [Online; accessed 14.05.2012].

[Jo13a] Joyent Inc.: High-performance Cloud Infrastructure for Real-time Weband Mobile Applications - Home - Joyent. http://joyent.com/.2013. [Online; accessed 04.03.2013].

[Jo13b] Joyent Inc.: Node.js v0.8.21 Manual & Documentation.http://nodejs.org/api/http.html#http_http_createserver_

requestlistener. 2013. [Online; accessed 04.03.2013].

[Ka13] Kaazing: About HTML5 WebSockets. http://www.websocket.org/

aboutwebsocket.html. 2013. [Online; accessed 14.05.2013].

[Kl12] Kleinschmager, S.; Hanenberg, S.; Robbes, R.; Tanter, É.; Stefik,A.: Do static type systems improve the maintainability of softwaresystems? An empirical study. In Program Comprehension (ICPC),2012 IEEE 20th International Conference on. pages 153–162. IEEE.2012.

[Le13] LearnBoost Labs: Socket.IO: the cross-browser WebSocket for realtimeapps - Supported transports. http://socket.io/#browser-support.2013. [Online; accessed 04.03.2013].

126

http://www.showdocument.com/

http://expressjs.com/

http://expressjs.com/

http://www.infoasset.de

http://video.nextconf.eu/video/1914374/nodejs-digs-dirt-about

http://video.nextconf.eu/video/1914374/nodejs-digs-dirt-about

http://www.jetbrains.com/idea/features/index.html

http://www.jetbrains.com/idea/features/index.html

http://www.jetbrains.com/webstorm/

http://www.jetbrains.com/webstorm/

http://joyent.com/

http://nodejs.org/api/http.html#http_http_createserver_requestlistener

http://nodejs.org/api/http.html#http_http_createserver_requestlistener

http://www.websocket.org/aboutwebsocket.html

http://www.websocket.org/aboutwebsocket.html

http://socket.io/#browser-support

Bibliography

[Lo04] Lowry, Paul Benjamin, Curtis, Aaron Mosiah and Lowry, M. R.: ATaxonomy of Collaborative Writing to Improve Empirical Research,Writing Practice, and Tool Development. Journal of Business Com-munication (JBC). 41:66–99. 2004.

[Ma11] MacCaw, A.: JavaScript Web Applications. O’Reilly Media. 2011.

[MC08] McCarthy, P.; Crane, D.: Comet and Reverse Ajax: The Next-Generation Ajax 2.0. 2008.

[Mi12] Microsoft: TypeScript preview. http://www.typescriptlang.org/.2012. [Online; accessed 24.01.2013].

[Mi13a] Microsoft: WebMatrix 2. http://www.microsoft.com/web/

webmatrix/. 2013. [Online; accessed 24.01.2013].

[Mi13b] Microsoft: Windows Azure Node.js Dev Center. http://www.

windowsazure.com/en-us/develop/nodejs/. 2013. [Online; ac-cessed 24.01.2013].

[MNS11] Matthes, F.; Neubert, C.; Steinhoff, A.: Hybrid wikis: Empoweringusers to collaboratively structure information. In 6th InternationalConference on Software and Data Technologies (ICSOFT). pages 250–259. 2011.

[Mo12] Moxiecode Systems AB.: TinyMCE - Home. http://www.tinymce.

com/. 2012. [Online; accessed 21.10.2012].

[Mo13] Mozilla Developer Network and individual contributors: HTTP accesscontrol (CORS). https://developer.mozilla.org/en-US/docs/

HTTP/Access_control_CORS. 2013. [Online; accessed 08.04.2013].

[MT07] Mikkonen, T.; Taivalsaari, A.: Using JavaScript as a Real Program-ming Language Using JavaScript as a Real Programming Language.2007.

[No12] Nodejitsu Inc.: Flatiron, A framework for Node.js. http://

flatironjs.org/. 2012. [Online; accessed 04.11.2012].

[O’12] O’Grady, S.: The RedMonk Programming Language Rankings:September 2012 – tecosystems. http://redmonk.com/sogrady/

2012/09/12/language-rankings-9-12/. 2012. [Online; accessed04.02.2012].

127

http://www.typescriptlang.org/

http://www.microsoft.com/web/webmatrix/

http://www.microsoft.com/web/webmatrix/

http://www.windowsazure.com/en-us/develop/nodejs/

http://www.windowsazure.com/en-us/develop/nodejs/

http://www.tinymce.com/


https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS

https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS

http://flatironjs.org/

http://flatironjs.org/

http://redmonk.com/sogrady/2012/09/12/language-rankings-9-12/

http://redmonk.com/sogrady/2012/09/12/language-rankings-9-12/

Bibliography

[PL11] Peter Lubbers, Brian Albers, F. S.: Pro HTML5 Programming.Apress. 2 edition. 2011.

[Po07] Powers, S.: Adding Ajax. O’Reilly Media. 2007.

[PT98] Prechelt, L.; Tichy, W. F.: A controlled experiment to assess the bene-fits of procedure argument type checking. Software Engineering, IEEETransactions on. 24(4):302–312. 1998.

[Ra12a] Rauch, G.: LearnBoost/socket.io-spec. https://github.com/

LearnBoost/socket.io-spec. 2012. [Online; accessed 04.03.2013].

[Ra12b] Rauch, G.: Socket.IO: the cross-browser WebSocket for realtime apps.http://socket.io/. 2012. [Online; accessed 04.03.2013].

[Ri10] Richards, G.; Lebresne, S.; Burg, B.; Vitek, J.: An analysis of thedynamic behavior of JavaScript programs. In ACM Sigplan Notices.volume 45. pages 1–12. ACM. 2010.

[Ro10] Roden, T.: Building the realtime user experience. O’Reilly Media.2010.

[SA09] Souders, S.; Almaer, D.: Even faster web sites. O’Reilly. Beijing ;Sebastopol, CA. 1st edition. 2009.

[Se12] Sencha Labs: Connect - High quality middleware for node.js. http://www.senchalabs.org/connect/. 2012. [Online; accessed 13.11.2012].

[SH11] Stuchlik, A.; Hanenberg, S.: Static vs. dynamic type systems: an em-pirical study about the relationship between type casts and developmenttime. In ACM SIGPLAN Notices. volume 47. pages 97–106. ACM.2011.

[Sh13] ShareLaTeX: LaTeX Editor ShareLaTeX - ShareLaTeX.com. https://www.sharelatex.com/. 2013. [Online; accessed 10.05.2013].

[Sp06] Spinellis, D.: Code Quality: The Open Source Perspective. Addison-Wesley Professional. 2006.

[Sp10] Spiewak, D.: Understanding and Applying OperationalTransformation. http://www.codecommit.com/blog/java/

understanding-and-applying-operational-transformation.2010. [Online; accessed 20.04.2013].

128

https://github.com/LearnBoost/socket.io-spec

https://github.com/LearnBoost/socket.io-spec

http://socket.io/

http://www.senchalabs.org/connect/

http://www.senchalabs.org/connect/

https://www.sharelatex.com/

https://www.sharelatex.com/

http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation

http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation

Bibliography

[Su04] Sun, D.; Xia, S.; Sun, C.; Chen, D.: Operational transformation forcollaborative word processing. Proceedings of the 2004 ACM conferenceon Computer supported cooperative work - CSCW ’04. 6(3):437. 2004.

[Su11] Sun, C.: OT FAQ - Operational Transformation Frequently AskedQuestions and Answers. http://cooffice.ntu.edu.sg/otfaq/

index.php. 2011. [Online; accessed 24.11.2012].

[SWF12] Sun, C.; Wen, H.; Fan, H.: Operational transformation for orthog-onal conflict resolution in real-time collaborative 2d editing systems.Proceedings of the ACM 2012 conference on Computer Supported Co-operative Work - CSCW ’12. page 1391. 2012.

[Te12] Teixeira, P.: Professional Node.js: Building Javascript Based ScalableSoftware. John Wiley & Sons. 1st edition. 2012.

[Th99] The Internet Engineering Task Force: RFC 2616 - Hypertext Trans-fer Protocol – HTTP/1.1. http://www.ietf.org/rfc/rfc2616.txt.1999. [Online; accessed 10.12.2012].

[Th12] The Apache Software Foundation: Apache Wave - Welcome to ApacheWave (Incubating). http://incubator.apache.org/wave/. 2012.[Online; accessed 12.05.2013].

[Th13] The Etherpad Foundation: Etherpad lite. http://etherpad.org/.2013. [Online; accessed 09.04.2013].

[Ti13a] Tilde Inc.: Ember.js - Concepts. http://emberjs.com/guides/

concepts/core-concepts/. 2013. [Online; accessed 03.04.2013].

[Ti13b] Tilde Inc.: Ember.js - Ember. http://emberjs.com/api/. 2013. [On-line; accessed 04.04.2013].

[Tw13] Twitter, I.: Bootstrap. http://twitter.github.com/bootstrap/.2013. [Online; accessed 03.04.2013].

[VM03] VMware, Inc: Redis. http://redis.io/. 2003. [Online; accessed27.02.2013].

[W3] W3C: XMLHttpRequest - W3C Working Draft 6 December 2012.http://www.w3.org/TR/XMLHttpRequest/. [Online; accessed11.12.2012].

129

http://cooffice.ntu.edu.sg/otfaq/index.php

http://cooffice.ntu.edu.sg/otfaq/index.php

http://www.ietf.org/rfc/rfc2616.txt

http://incubator.apache.org/wave/

http://etherpad.org/

http://emberjs.com/guides/concepts/core-concepts/

http://emberjs.com/guides/concepts/core-concepts/

http://emberjs.com/api/

http://twitter.github.com/bootstrap/

http://redis.io/

http://www.w3.org/TR/XMLHttpRequest/

Bibliography

[W312] W3C: Share: News and Opinions about HTML. http://www.w3.org/html/. 2012. [Online; accessed 11.12.2012].

[Wa11] Warden, P.: Big Data Glossary. O’Reilly Media. 2011.

[Wi11] Wieland, K.; Langer, P.; Seidl, M.; Wimmer, M.; Kappel, G.: TurningConflicts into Collaboration. Computer Supported Cooperative Work(CSCW). pages 1–60. 2011.

[WML10] Wang, D.; Mah, A.; Lassen, S.: Google Wave OperationalTransformation. http://wave-protocol.googlecode.com/hg/

whitepapers/operational-transform/operational-transform.

html. 2010. [Online; accessed 18.04.2013].

[Zo13] Zoho Corporation Pvt. Ltd.: More than 7 Million users Work Onlinewith Zoho. https://www.zoho.com/. 2013.

130

http://www.w3.org/html/

http://www.w3.org/html/

http://wave-protocol.googlecode.com/hg/whitepapers/operational-transform/operational-transform.html



https://www.zoho.com/

A. Survey

A.1. Survey Question

The survey is divided into three parts. The first one asks JavaScript specificquestions, the second one deals with Node.js, whereas the last part addressesthe organization, the participant is working in. The questions of all three partsare presented in the following sections.

A.1.1. Java Script

1. Are you using or have you ever been in contact to JavaScript? (multiple answers allowed)

# I use JavaScript in a privateproject

# I work in a project, whereJavaScript is used

# I actively develop withJavaScript

# I’ve used JavaScript in thepast

# I’ve never used JavaScript andhave no experience with it

# Other:

2. What programming languages are mostly used in your projectsdespite of JavaScript ? (multiple answers allowed)

# C

# C++

# C#

# Java

# PHP

# HTML

# Python

# Ruby

# Perl

# ObjectiveC

# Scala

# Haskell

# Lua

# Erlang

# Prolog

# Visual Ba-sic

# ASP

# Go

# Shell

# Power Shell

# Other:

131

A. Survey132

3. How much of your code is written in JavaScript (measured inlines of code) in your projects in average ?

# 0%

# 1% - 10%

# 11% - 20%

# 21% - 30%

# 31% - 40%

# 41% - 50%

# 51% - 60%

# 61% - 70%

# 71% - 80%

# 81% - 90%

# 91% - 99%

# 100%

4. Which editors/IDEs do you use to program in JavaScript ?

# Suiblime Text

# Vim

# Emacs

# TextMate

# Eclipse

# NetBeans

# Notepad++

# Visual Studio

# WebStorm

# Komodo

# IntelliJ

# Aptana

# Other:

5. Are you fully satisfied with the features of your editors/IDEsrelated to JavaScript programming ?# Yes # No # No answer

6. Which features are you missing in your editor/IDE related toJavaScript programming ?

7. Are you using any testing-frameworks for your JavaScript Code?# Yes # No # No answer

8. Which testing-frameworks do you use for your JavaScript Code?

# QUnit

# Jasmine

# JSUnit

# RhinoUnit

# Buster.js

# TestSwarm

# JsTestDriver

# Yeti

# Sinon.JS

# Chutzpah

# Other:

A. Survey133

9. What other testing-frameworks do you use ?

Please evaluate the following statements about JavaScript and statewhether you agree or disagree.

10. JavaScript is important for my projectsstrongly disagree #—#—#—# strongly agree No answer #

11. The general importance of JavaScript will rise in futurestrongly agree #—#—#—# strongly disagree No answer #

12. JavaScript code is easy to structurestrongly agree #—#—#—# strongly disagree No answer #

13. JavaScript code is hard to maintainstrongly agree #—#—#—# strongly disagree No answer #

14. JavaScript code is hard to refactorstrongly agree #—#—#—# strongly disagree No answer #

15. JavaScript code is easy to readstrongly agree #—#—#—# strongly disagree No answer #

16. I’m fully satisfied with the performance of JavaScriptstrongly agree #—#—#—# strongly disagree No answer #

17. I prefer clientside processing (instead of serverside)strongly agree #—#—#—# strongly disagree No answer #

18. I like the syntax of JavaScriptstrongly agree #—#—#—# strongly disagree No answer #

19. Have you ever heard of CoffeeScript ?# Yes # No

20. How much of your JavaScript code is written in CoffeeScript ?

A. Survey134

# 0%

# 0% - 49%

# 50% - 99%

# 100%

21. What are the main reasons for you using CoffeeScript ?

22. What are the main reasons for you to not use CoffeeScript ?

23. Are you planning to use CoffeeScript in future ?# Yes # No # No answer

24. What are the main reasons for you to use CoffeeScript in future?

25. Have you ever heard of TypeScript ?# Yes # No

26. How much of your JavaScript code is written in TypeScript ?

# 0%

# 0% - 49%

# 50% - 99%

# 100%

27. What are the main reasons for you to use TypeScript ?

28. What are the main reasons for you to not use TypeScript ?

29. Are you planning to use TypeScript in future ?# Yes # No # No answer

30. Why are you planning to use TypeScript in future ?

31. Are you using any JavaScript frameworks or libraries ?# Yes # No # No answer

32. Which JavaScript Frameworks/libraries do you use ?

A. Survey135

# jQuery

# Prototype

# Cappucino

# MooTools

# JavaScriptMVC

# Backbone.js

# ExtJS

# Angular

# Knockout

# PureMVC

# batman.js

# YUI

# Ember

# Spine

# Others:

33. Which additional JavaScript frameworks/libraries do you use ?

34. If you want to state any further comments or impressions aboutJavaScript please do so in the following.

A.1.2. Node.js

35. Have you ever heard of Node.js ?# Yes # No

36. Where did you first hear about Node.js ? Please give a moredetailed source in the comment-field.

# Magazine

# Internet News

# Friends

# Business

# Conference

# Others:

37. Do you actively develop with Node.js or is it used in one ofyour projects ?# Yes # No

38. What is the context of your project ?.

# Private

# Business

# Open Source Project

# Others:

39. When was the project start ?

A. Survey136

40. How many people are working in your project ?

41. Whats the name of the Open Source Project ?

42. What kind of project are you developing ?

# Web Application

# Framework

# Command LineTool

# Embedded

# Desktop Applica-tion

# Others:

43. Please describe your project in a few words

44. Please upload some screenshots of your project

45. What were the main reasons for choosing Node.js for yourproject ?

46. Did you ever consider to use Node in one of your projects ?# Yes # No

47. Why did you decide against Node ?

48. What were the main reasons for not considering Node at all ?

49. Are you planning to use Node in future ?# Yes # No # No answer

50. Do you use any frameworks on top of Node.js ?# Yes # No

51. Which frameworks do you use on top of Node.js ?

A. Survey137

# Derby

# Meteor

#

SocketStream

# TowerJS

# Express

# GeddyJS

# nowJS

# flatiron

# restify

# Others:

52. Which frameworks are you using addtitionally on top of Node.js?

53. Do you use testing frameworks for your Node.js code ?# Yes # No

54. Which testing frameworks do you use ?

# Mocha

# Vows

# should

# Jasmine

# Expresso

# NodeUnit

# Others:

55. Which additional testing frameworks are you using for yourNode.js code ?

Please evaluate the following statements and state whether you agreeor disagree

56. Node.js is important for my projectsstrongly disagree #—#—#—# strongly agree No answer #

57. The general importance of Node.js will rise in futurestrongly agree #—#—#—# strongly disagree No answer #

58. I’m fully satisfied with the performance of Node.jsstrongly agree #—#—#—# strongly disagree No answer #

59. Do you think Node.js is suitable for enterprise applications ?# Yes # No # No answer

A. Survey138

60. What are the reasons for Node.js being not suitable for enter-prise applications in your opinion ?

61. What are the reasons for Node.js being suitable for enterpriseapplications in your opinion ?

62. What functionality or module are you missing currently whichyou wish to be implemented ?

63. If you want to state any further comments or impressions aboutNode.js please do so in the following.

A.1.3. Your Company

64. Whats the name of your organization ?

65. What industry does your organization belong to ?

# Aerospace

# Education (e.g.professor, (gradu-ate) student)

# Finance (banks,insurance compa-nies)

# Health

# IT Consulting

# IT Products andServices

# ManagementConsulting

# Production andmanufacturing

# Automotive

# Public service

# Telecommunications

# Transport / Lo-gistics

# Open Source

# Other:

66. What kind of project does your organization typically have ?

A. Survey139

# Embedded

# Cloud Comput-ing

# Web development

# Desktop Applica-tions

# Security Applica-tions

# Other:

67. How many employees work at your organization ?

68. What is your current role within the organization ?

# Business Archi-tect

# Consultant

# CXO

# Enterprise Archi-tect

# IT Architect

# IT Operations

# Software Engi-neer

# Subject MatterExpert

# Software Tester

# Project Manager

# Other:

69. In which country do you work currently ?

70. When was your company founded (year) ?

71. What is your current role within the organization ?

# Scrum

# V-Modell

# V-ModellXT

# WaterfallModel

# Kanban

# Other:

Please evaluate the following statement and state whether you agreeor disagree

72. My organization is an early adopter related to new technologiesstrongly disagree #—#—#—# strongly agree No answer #

A. Survey140

73. Do you want to be informed about the results of the survey ?# Yes # No

74. Would you be willing to answer further questions ?# Yes # No

75. Please provide your contact eMail address

A.2. General Statements about JavaScript

The following presents some selected cites out of the 16 statements:

The biggest thing missing from JavaScript is education. Too many badprogrammers think they can use it, but have no clue.

JavaScript is important because it is the only viable option for web-basedRIA’s, not because it’s actually a good language.

I think javascript together with html5 and css3 makes some of the commonweb development technologies obsolete. Especially device independent

development will be more efficient. However in enterprise environment thereis a need of more matured frameworks and better integration with emerging

technologies like closure.

I have found JavaScript itself to be great, especially when mostly followingJsLint and The Good Parts. I’m excited to see where the language is headedwith many of the new features that have been proposed. I have found that

dealing with browsers is much more of a pain. Many of the standardized APIsare very strange and there are many weird edge cases when different browserswork differently or haven’t implemented the same features. Browsers are whatmade JavaScript what it is, but now they seem like a limitation. JavaScript’sbad parts aren’t completely getting fixed because no one wants to force people

to rewrite their old code.

I think that with the evolution of Javascript on server side, and with thecombination of Html5 and CSS3. Javascript is going to be lead programming

language of the future.

A. Survey141

Once you’re getting used to it, you wouldn’t use anything else. Theasynchronous paradigm is awesome.

A.3. General Statements about Node.js

Do not build monolithic apps with Node, compose services and RESTinterfaces. Know what ‘node debug‘ does. Also, watch your memory usageand if you actually need to buffer / allocate objects. These are the majorpitfalls of people in many languages but Node’s adopters seem to findthemselves unable to research the solutions to these for some reason.

Node.js is great! There seems to be a ton of people who don’t like it and I feellike the controversy might be causing others to decide not to use it. It’s finefor people to have their own opinions, I just wish Node.js had a better public

image. Most of the problem seems to be because people don’t like usingcallback functions. I understand that for beginners it’s not immediately clearthe best way to handle non-trivial cases when several asynchronous operationsare going on at once or when asynchronous operations need to be chainedtogether, but there are many very simple ways to address these problems.There must be some better way to combat the idea that callbacks are hard.

It is great! Enjoying every minute.

Still in it’s infancy, but stable enough to use in production.

Never had a development environment that strong.

After developing with node for nearly two years, anything else I use seemsantiquated.

I am thinking to switch my career to : Node.js, html5, css3, Nosql etc

callback style of development is immediate a turn off, you really have toswitch the way you think.

Node will likely be a good choice for certain kinds of enterprise applicationsonce it stabilizes, though I’m still not a fan of JavaScript in general.

B. Implementation of the collaborativeeditor

B.1. Supported browsers by socket.io

Socket.io supports the following browsers:

B.1.1. Desktop Browsers

Browser Minimum VersionInternet Explorer 5.5Safari 3Google Chrome 4Firefox 3Opera 10.61

Table B.1.: Supported Desktop Browsers by socket.io134

B.1.2. Mobile Browsers

BrowseriPhone SafariiPad SafariAndroid WebKitWebOs WebKit

Table B.2.: Supported Mobile Browsers by socket.io135

134cf. [Le13]135cf. [Le13]

142

B. Implementation of the collaborative editor

B.2. Third party libraries used by the client

Name Homepage Description

Bootstrap http://twitter.

github.io/

bootstrap/

Front-end Framework

Bootstrap-dropdown

http://twitter.

github.io/

bootstrap/

Library for Bootstrap drop downmenus

Bootstrap-tooltip

http://twitter.

github.io/

bootstrap/

Library for Bootstrap tooltips

jQuery http://jquery.com/ JavaScript library fur multiple func-tionalities like HTML documenttraversal and manipulation or eventhandling

jQuery UI http://jqueryui.

com/

Pre-developed user interface ele-ments, effects, widgets or themes

Tag-it https://github.com/

aehlke/tag-it

JavaScript library that provides tag-ging functionalities and animation

Spectrum http://bgrins.

github.io/spectrum/

A colorpicker

Share.JS http://sharejs.org/ The client-library for Node.js’ liveconcurrent editing library

Browser-Channel

https://github.

com/josephg/

node-browserchannel

The client-library for using theBrowserChannel server

TinyMCE http://www.tinymce.

com/

Javascript WYSIWYG editor withrich set of features

Ember.js http://emberjs.com/ Web-application frameworkHandlebars http://

handlebarsjs.com/

Templating framework

socket.io http://socket.io/ Library that enables realtime com-munication with the server

Table B.3.: Third party libraries used by the client

143

http://twitter.github.io/bootstrap/









http://jquery.com/

http://jqueryui.com/

http://jqueryui.com/

https://github.com/aehlke/tag-it

https://github.com/aehlke/tag-it

http://bgrins.github.io/spectrum/

http://bgrins.github.io/spectrum/

http://sharejs.org/






http://emberjs.com/

http://handlebarsjs.com/

http://handlebarsjs.com/

http://socket.io/