Framework de aplicaciones para red social colaborativa distribuida

Framework de aplicaciones para red social colaborativa distribuida Pablo Mart´ınez Bernardo Grado en Ingenier´ıa Inform´atica Facultad de Inform´atica UNIVERSIDAD COMPLUTENSE DE MADRID Trabajo de Fin de Grado Madrid, junio 2014 Directores: Samer Hassan Collado Antonio Tenorio Forn´es Authorization of dissemination and usage Autorizo a la Universidad Complutense de Madrid a difundir y utilizar con fines acad´emicos, no comerciales y mencionando expresamente a su autor, tanto la propia memoria, como el c´odigo, la documentaci´on y/o el software desarrollado. Pablo Mart´ınez Bernardo Madrid, junio 2014 Copyleft by Pablo Mart´ınez Bernardo 2014, released under the license Creative Commons Attribution Share-Alike International 4.0 available at: https://creativecommons.org/licenses/by-sa/4.0/ III Contents Page Authorization III Abstract IX Resumen XI 1 Introduction 1 1.1 Objectives............................. 2 1.2 Document Structure . . . . . . . . . . . . . . . . . . . . . . . 3 2 Introducci´on 5 2.1 Objetivos ............................. 6 2.2 Estructura del Documento . . . . . . . . . . . . . . . . . . . . 7 3 State of the Art 9 3.1 GenericOverview......................... 9 3.2 State of the Art for Extensions . . . . . . . . . . . . . . . . . 11 4 Technologies and Methods 13 4.1 Technologies............................ 13 4.1.1 Wave............................ 13 4.1.2 Google Web Toolkit . . . . . . . . . . . . . . . . . . . 14 4.1.3 GadgetsAPI ....................... 15 4.1.4 RobotsAPI........................ 16 4.1.5 Other Technologies . . . . . . . . . . . . . . . . . . . . 16 4.2 Methods.............................. 17 4.2.1 Free Open Source Software Approach . . . . . . . . . . 17 4.2.2 Standards & Protocols . . . . . . . . . . . . . . . . . . 18 4.2.3 Patterns.......................... 19 4.2.4 Extensions......................... 20 V 5 Frame for Development of Gadgets & Robots 21 5.1 Gadgets .............................. 21 5.2 Robots............................... 25 6 CCWave: A Wave Gadget 29 6.1 StateoftheArt.......................... 29 6.2 Results............................... 31 6.3 Conclusions and Future Work . . . . . . . . . . . . . . . . . . 32 7 Pollymer: A Wave Gadget 33 7.1 StateoftheArt.......................... 33 7.2 Results............................... 34 7.3 Conclusions and Future Work . . . . . . . . . . . . . . . . . . 36 8 AppearWOW: A Wave Gadget 39 8.1 StateoftheArt.......................... 39 8.2 Results............................... 40 8.3 Conclusions and Future Work . . . . . . . . . . . . . . . . . . 42 9 Colbotia: A Wave Robot 43 9.1 StateoftheArt.......................... 43 9.2 Results............................... 44 9.3 Conclusions and Future Work . . . . . . . . . . . . . . . . . . 47 10 Concluding Remarks 49 10.1 Discussion of Overall Results . . . . . . . . . . . . . . . . . . . 49 10.2Conclusion............................. 51 10.3FutureWork............................ 52 Bibliography 52 List of Figures 3.1 iGooglein2008 .......................... 10 3.2 Google Wave Gadgets . . . . . . . . . . . . . . . . . . . . . . 11 4.1 KuneGroups ........................... 14 4.2 GWTShowcase.......................... 15 4.3 Technologies Used . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4 UML Class Diagram, Wave Structure . . . . . . . . . . . . . . 19 5.1 UML Sequence Diagram, Wave state transmission . . . . . . . 22 5.2 UML Class Diagram, Gadgets API class structure . . . . . . . 23 5.3 UML Class Diagram, Gadget Tester Structure . . . . . . . . . 23 5.4 UML Class Diagram, Gadget Deployer Structure . . . . . . . . 24 5.5 Robot Registration Screen . . . . . . . . . . . . . . . . . . . . 25 6.1 CCWave.............................. 31 7.1 Poll................................. 33 7.2 Consensuall ............................ 34 7.3 Pollymer.............................. 34 7.4 UML Class Diagram, Pollymer . . . . . . . . . . . . . . . . . . 35 7.5 PollymerVoters.......................... 36 8.1 Hangouts and Skype . . . . . . . . . . . . . . . . . . . . . . . 40 8.2 Room Selection Screen . . . . . . . . . . . . . . . . . . . . . . 40 8.3 Video Conference Gadget . . . . . . . . . . . . . . . . . . . . . 41 8.4 UML Sequence Diagram, AppearWOW . . . . . . . . . . . . . 42 9.1 Blip Participants in Apache Wave . . . . . . . . . . . . . . . . 43 9.2 Change Highlighting in Apache Wave . . . . . . . . . . . . . . 44 9.3 TitanPad ............................. 44 9.4 ColbotiaColours ......................... 45 9.5 Colbotia Tracking Participants . . . . . . . . . . . . . . . . . . 45 9.6 UML Class Diagram, Colbotia . . . . . . . . . . . . . . . . . . 46 VII 9.7 UML Activity Diagram, Colbotia . . . . . . . . . . . . . . . . 47 List of Tables 4.1 Technologies Summary . . . . . . . . . . . . . . . . . . . . . . 16 6.1 Available Creative Commons licenses . . . . . . . . . . . . . . 30 10.1 Extensions Summary . . . . . . . . . . . . . . . . . . . . . . . 50 Abstract Real-time online collaborative software grants the user a broad collection of alternatives including, yet not limited to, concurrent document edition, gaming and technical applications. It is a field of increasing importance and still not fully exploited potential. Apache Wave provides a standard for federated real-time collaboration allowing the usage of small applications with collaborative purpose named Gadgets, embedded in particular online documents. However the amount of activity regarding Apache Wave declined in the recent past and there exists a concerning lack of information relative to the development of Gadgets. Accompanying that, there are also important needs solvable with Gadgets that have not been implemented. This work explores the scene of Wave, and specifically attemps to set the base for real-world developers to code collaborative applications under the Wave infrastructure. In the frame of this work Several different extensions to Apache Wave have been developed taking advantage of open source software, open protocols and open standards. Besides, undocumented features and procedures to help developers have been detailed. The developed extensions are the following: a gadget to set an open license to your content, a gadget for decision making, a gadget for video conference, and another extension for highlighting the contributions of each participant in a document. Information about the development and use of extensions has been documented and shared publicly. The results of this project constitute a framework that aids developers attemping to code extensions for Apache Wave by gathering and creating information about the process, as well as implementing four extensions that are both needed in the community and representative of key functionalities. Keywords: Apache Wave, Collaboration, Gadgets, Apps, Real Time, Federation, Google Web Toolkit IX CHAPTER 1. INTRODUCTION •Chapter 4 - Technologies and methods: every procedure and technology that has been used along this work. •Chapter 5 - Frame for Development of Gadgets & Robots: how Gadgets and Robots work. How to get them running. •Chapter 6 - CCWave: development of a Wave gadget for choosing a Creative Commons License. •Chapter 7 - Pollymer: development of a Wave gadget for decision making. •Chapter 8 - AppearWOW: development of a Wave gadget for video conference. •Chapter 9 - Colbotia: development of a Wave robot for colorizing the contributions of each participant. •Chapter 10 - Concluding Remarks: comments and analysis on the whole project. 4 Chapter 2 Introducci´on Hoy en d´ıa las redes sociales en l´ınea tales como Facebook o Google+ son de gran importancia en el uso convencional de Internet. Numerosas redes sociales han surgido en un corto per´ıodo de tiempo, han sido diferentes e innovativas, y disfrutan de una creciente importancia fuera de la red. Uno de esos destacables intentos fue Google Wave, que tuvo una breve existencia antes de que Google decidiera dejar de dar soporte para ´el y desarrollarlo, e incluso desactiv´o los nodos que hab´ıan estado funcionando hasta entonces. El control del proyecto le fue otorgado a Apache para que continuara con su desarrollo. Desde el origen de Wave, la web ha sufrido numerosos cambios, pero la tecnolog´ıa y el protocolo de Wave siguen hoy en d´ıa siendo relevantes. JavaScript es una de las tecnolog´ıas web m´as usadas hoy en d´ıa para ejecutar c´odigo en el cliente. El mundo ha girado en el sentido de “la nube”: las aplicaciones cada vez m´as son extra´ıdas del ordenador del usuario y almacenadas en una localizaci´on remota para interactuar con ellas y compartirlas. Una de las principales ventajas de “la nube” es que facilita el intercambio entre usuarios, distribuir creaciones entre otras personas. Existe un concepto similar al de intercambio: colaboraci´on, o usar aplicaciones de manera simult´anea con otras personas y en tiempo real (O tiempo casi real) para ver el resultado a la vez. Wave siempre mantuvo cerca el concepto de colaboraci´on, y todo en ´el estaba dise˜nado para colaborar. Otro exitoso producto de Google relacionado con la colaboraci´on es Google Docs [1], que antedata a Wave, y por ellos desde entonces han existido otras aplicaciones colaborativas como Zoho [2], Pads (Explicados en la Secci´on 9.1) y otros. Acompa˜nando al crecimiento de la red social Facebook, desarrollaron varias nuevas utilidades, y una de ellas est´a muy relacionada con este trabajo y son las Apps Facebook: aplicaciones desarrolladas por terceros e integradas dentro de Facebook usando algunas de sus caracter´ısticas. Cuando Google anunci´o Wave fue una innovaci´on, y atrajo una atenci´on 5 CHAPTER 2. INTRODUCCI´ ON positiva. Google, decepcionados por una mala acogida del producto, a pesar de la buena aceptaci´on por parte de los desarrolladores, decidieron ponerle fin al proyecto. No hicieron que desapareciera completamente, en su lugar eligieron otorgarle el proyecto a Apache con la intenci´on de que continuara el desarrollo, y lo pusieron en el Apache Incubator, un programa para ayudar a prometedores proyectos de software libre con el objetivo de acabar incorpor´andolos como proyectos de la Apache Foundation cuando est´en lo suficientemente maduros. Dos de las caracter´ısticas de Wave desde el principio han sido los Robots y los Gadgets: formas de extender las capacidades de Wave sin la necesidad de integrar nada en el software de Wave, as´ı que pueden ser hechos y modificados de manera independiente. Los Gadgets son aplicaciones separadas pero empotradas dentro de una entidad m´as potente que ellos y que se encarga de contenerlos. Los Robots interact´uan con esa misma entidad y pueden reacci´onar a sus cambios y eventos. El objetivo general de este trabajo es crear un marco alrededor de Wave basado en Gadgets y Robots y as´ı explorar sus funcionalidades, ayudar a documentar sus caracter´ısticas y uso, adem´as de cimientar una base para que estos dos tipos de extensiones puedan seguir siendo exploradas y mejoradas en un futuro. El proyecto P2Pvalue [3] ha inspirado tanto la existencia de este trabajo as´ı como lo que era necesario hacer. P2Pvalue es una “Plataforma tecno-social para modelos sostenibles y generaci´on de valor en la producci´on de iguales basada en lo com´un en el Internet Futuro”, est´an estudiando diferentes aspectos de las redes sociales, y construyendo una plataforma online colaborativa basada en Wave para promover “comunidades de producci´on colaborativa”. El objectivo de este proyecto es un framework, entendido como la estructura que soporta un conglomerado de elementos con una intenci´on o contexto similares. Cuando Google dej´o de dar soporte para Wave, tambi´en empezaron lentamente a eliminar p´aginas web con informaci´on muy importante sobre Wave, y partes de esa informaci´on se han perdido. 2.1 Objetivos Para este proyecto de fin de grado estaba pensado que no fuera simplemente un ejercicio m´as, sino llevar a cabo contribuciones reales a proyectos existentes. Por lo tanto se unen todas las piezas relacionadas con los Gadgets y 6 CHAPTER 2. INTRODUCCI´ ON Robots, se prueba todo lo que tenga que ver con ellos y se dibuja un camino que podr´a ser seguido m´as adelante. Para ello hay que documentar y probar todas las caracter´ısticas que se ponen a nuestra disposici´on gracias a todas las APIs. De todas maneras ´esa no es la ´unica intenci´on, tambi´en es importante hacer algunas aportaciones tangibles en forma de extensiones como Robots y Gadgets que sean ´utiles para la comunidad de Wave, y que satisfagan necesidadas existentes que todav´ıa no han sido solventadas. Todo el proceso se ha liberado en c´odigo y otorgado una licencia libre [4] para que otras personas puedan analizarlo y mejorarlo. El proyecto P2Pvalue [3] ha sido una gran influencia en cuanto a qu´e caracter´ısticas eran m´as necesitadas, y algunas de ellas han sido completadas satisfactoriamente. •Documentaci´on de Wave –Mejorar documentaci´on existente –Documentar caracter´ısticas no documentadas •Proyectos –Actualizar proyectos ya existentes –Generar nuevas extensiones ´utiles •Uso –Explicar procedimientos no documentados –Ense˜nar c´omo introducirse al desarrollo de extensiones Wave 2.2 Estructura del Documento Todos esos elementos que componen el framework ser´an explorados de manera individual. Pueden ser descritos individualmente, pero a su vez se puede describir el framework como unidad. Hay disponibles resultados globales as´ı como individuales, y todos ellos est´an organizados de la siguiente manera: en primer lugar se encuentra un Estado del Arte general as´ı como unos M´etodos, y despu´es cada elemento se explica completamente de manera indificual con su propia introducci´on, estado del arte, resultados y conclusiones. Finalmente se alcanzan unas conclusiones globales. Adem´as de eso, cada 7 CHAPTER 2. INTRODUCCI´ ON extensi´on tiene sus propios resultados, conclusiones y trabajo futuro, pero el trabajo completo es analizado tambi´en como una entidad individual. Los objetivos del framework en s´ı mismo son los descritos arriba, pero todas las extensiones son un proyecto completo en ellas mismas, por lo que tienen objetivos espec´ıficos. •Cap´ıtulo 3 - Estado del Arte: alternativas a los Robots y Gadgets de Wave. •Cap´ıtulo 4 - M´etodos y Tecnolog´ıas: cada procedimiento y tecnolog´ıa que hayan sido usados a lo largo de este trabajo. •Cap´ıtulo 5 - Marco para el Desarrollo de Gadgets y Robots: c´omo funcionan los Gadgets y Robots. C´omo se pueden ejecutar. •Cap´ıtulo 6 - CCWave: desarrollo de un gadget de Wave para elegir una licencia Creative Commons. •Cap´ıtulo 7 - Pollymer: desarrollo de un gadget de Wave para toma de decisiones. •Cap´ıtulo 8 - AppearWOW: desarrollo de un gadget de Wave para realizar v´ıdeo conferencias. •Cap´ıtulo 9 - Colbotia: desarrollo de un robot de Wave para colorear las contribuciones de los participantes. •Cap´ıtulo 10 - Comentarios Conclusivos: comentarios y an´alisis del proyecto completo. 8 Chapter 3 State of the Art This chapter will explore the global state of the art related to this work, and the evolution of gadgets and robots along the existence of the Internet. 3.1 Generic Overview The concept of gadgets might have born with the name of apps in Google’s “Google Personalized Homepage” in 2005 [5], later to be called iGoogle (Figure 3.1) and rename these components to gadgets. There is an important distinction to make: Nowadays hearing the words apps reminds us of portable phone applications. The word app insinuates smaller size and lesser complexity, and that is true for both kind of apps, but this work is exploring those applications than run inside a bigger environment and are embedded in it, extending it, but are not standalone and complete by themselves, they depend on the parent framework. The social aspect of this apps was being able to share your gadgets with other people, and some examples of them would be weather apps, stock apps or video-watching apps. In the latest years of iGoogle’s life, before being discounted in 2012, iGoogle apps coexisted with Google Wave [6], and Google Wave’s Gadgets (Figure 3.2). This other gadgets offered the advantage of the Federated Wave Protocol [7] and real-time collaboration [8]. Then Google began pushing Google+ [9], which can be considered to have some kind of gadgets in the shape of games, which were heavily influenced by Facebook games [10], allowing users to play with other people from the same social networks, giving gifts and sharing scores. Google also briefly had Spreadsheet Gadgets, which added unusual functionality for a spreadsheet application in Google Docs. 9 CHAPTER 3. STATE OF THE ART Figure 3.1: iGoogle in 2008 But Google has not been the only player in the world of applications. In the neat past Flash [11] components have been omnipresent, basically for games but not limited for them. Another alternative for applications in the web are Java Applets [12], commonly use for scientific and learning purposes. The other aspect explored in this work are robots, also known as bots. Robots usually interact loosely coupled from the software they are meant to interact with, but as with Wave Gadgets, robots can be incorporated in the main software, acting as an extension to it. An example of this are uNrEaL Bot [13], a collection of robots for very popular video games created to give the user an advantage over the rest of the players, integrating the graphical interface inside the game, and altering the game’s own engine. Robots are also important in the web world itself, but they are not usually productive bots, but instead robots made to emulate human behaviour to trick systems and people and get some kind of profit from it. It has been estimated that one third of the world’s Internet traffic is made by automated robots [14]. But this robots are different in the aspect that they are not 10 CHAPTER 3. STATE OF THE ART Figure 3.2: Google Wave Gadgets meant to be: There is no intended resources for them and they take advantage of vulnerabilities, so as a result they can not run in harmony with the parent software, but as a parasite. 3.2 State of the Art for Extensions As several extensions will been seen here, the specific state of the art concerning each of them has been explored deeper in their specific sections 6.1, 7.1, 8.1 and 9.1 respectively, so they are closer to their context. 11 Chapter 4 Technologies and Methods This chapter will explain all of the technologies and techniques that have been used and applied to finish this work. 4.1 Technologies Multiple utilities for a wide variety of purposes have been used. Some of them such as the choice of web server or Integrated Development Environment are alternatives selected for their personal perception of fitness to the task to solve. Others such as Wave and the Google Web toolkit are essential and irreplaceable. 4.1.1 Wave Wave can be interpreted as different things: The project formerly known as Google Wave and now Apache Wave, the system Wave In A Box which is the main focus of the Apache Wave project, the communication protocol inside Wave In A Box created by Google for human communication and inspired in email, or one of the units of communication inside this protocol. In the making of this work every extension has been developed and tested under two varieties of Wave: Wave In A Box and Kune [15]. Kune nowadays has much of its code forked from the Wave In A Box repository, but adding more functionality around it or changing it. Gadgets and apps are built into the core of Wave, and, as such, Kune inherits all their capabilities, making the gadgets and robots explored here compatible with both technologies. The people behind Kune are Colectivo Comunes [16], a non-profit collective that tries to help other collectives to carry their operations by developing some web tools and free resources. 13 CHAPTER 4. TECHNOLOGIES AND METHODS 4.2.4 Extensions Both possible ways for extending Wave have been explored in this work. Gadgets have been implemented with the Wave Gadgets API, and robots with the Java version of the robots API. To understand where these extensions live, it is necessary to understand how wave is structured. In Figure 4.4 you can see how Wave documents are structured. The outermost layer is the wave, a thread or conversation, the whole picture of a conversation. Users are invited to the wave, letting them participate in any of the inner wavelets, when they then become participants. As of today, in current versions of Wave In A Box and Kune, there is only one wavelet inside every wave, but the Wave Protocol allows for multiple wavelets. Blips are individual messages created by a participant, and edited by participants later. Blips have hierarchical structure and can be nested inside other blips. Blips also contain a document in XML-like format, which is the text itself plus all the variations that Wave supports such as annotations. 20 Chapter 5 Frame for Development of Gadgets & Robots As stated before, there is an important lack of documentation affecting anything relating to Wave. Through the progression of this project some obstacles, and the following chapter describes how they can be overcome. In addition to that, it explains the structure followed to implement the extensions as well as the operation of part of the features in Wave. 5.1 Gadgets As explained before, gadgets are applications by themselves, but depending on some bigger entity, in this case the Wave server. Gadgets are inserted inside a document, together with the content itself. They are placed inside a blip, but belong to the wave and therefore have access to the whole wave’s content, which is given access by the Gadgets API. But that access is very limited, almost only to access what is called the wave’s state, a key-value dictionary that keeps track of every state change that occurs inside the wave. There is actually two differentiated kind of states in a wave: •Private State: stores information that can only be accessed and modified from the participant that created it. Useful to keep stored private information that is not intended to be shared. •Shared State: stores the global state of every gadget in this wave, representing the whole picture. Useful for communicating with the other participants and collaborating or communicating in the gadget. It is important to know that the state belongs to the wave, so gadgets will have access to the other gadgets state, even different instances of the same 21 CHAPTER 5. FRAME FOR DEVELOPMENT OF GADGETS & ROBOTS gadgets. It is then good practice to adopt a system similar to namespaces in programming languages, appending an identifier of the gadget before the key in a way we are not altering or reading an unintended state. Each actual instance of the gadget in a participant’s browser is local, variables are not shared in any way between different participants. When a user triggers a state change in his local instance of the gadget, the only thing that can be communicated outside of the browser is a delta, that is an addition, deletion or modification in the key-value pairs that represent the state. This delta is then communicated to the local instance of the gadget in every client’s browser so they can act accordingly and represent the new state. That behaviour can be seen illustrated in figure 5.1. Figure 5.1: UML Sequence Diagram, Wave state transmission The Gadgets API asks you to follow a class hierarchy in order to be able to correctly communicate with wave. That hierarchy is as seen in Figure 5.2. Those classes will interact in the following way: •AbstractGinModule: GIN is Guice for GWT client-side code, built on top of Guice and with a subset of Guice binding language. It allows the programmer to follow the pattern of dependency injection. This module attaches all of the modules together. •Composite: Is the actual visual representation of the gadget. This is a GWT class ideated for creating custom widgets. Composites can contain a panel, and inside the panel complex GWT component hier22 CHAPTER 5. FRAME FOR DEVELOPMENT OF GADGETS & ROBOTS Figure 5.2: UML Class Diagram, Gadgets API class structure archies can be built. All features of GWT are supported thanks to this component. •Messages: A GWT interface meant to be implemented by a class that gives access to the strings needed to build the interface. Those strings can be localised to make the gadget available in different languages for each client. The locale is determined by the Accept-Language field in the browser’s HTTP request [35] and served at runtime to the browser. Typically this class will be used from the Composite, or any of its inner components, to fill them with human-readable language. With every one of the gadgets there is available a tester and a deployer, both of them depending on the main gadget, which is common for both. Figure 5.3: UML Class Diagram, Gadget Tester Structure The tester project seen in Figure 5.3 shows the common class hierarchy used in every one of the tester projects, which makes use of the development 23 CHAPTER 5. FRAME FOR DEVELOPMENT OF GADGETS & ROBOTS mode available in GWT, so gadgets can be quickly tested before deploying them. It is linked to the one seen in Figure 5.2 by the GadgetGinModule, which is inherited by the GadgetTesterGinModule. This new Gin module adds another injection, the WaveMock. This is a mock class that simulates the basics of the behaviour of the Wave infrastructure without the need to deploy the whole Wave system. To complete the needs of GIN a class extending Ginjector is created, the TesterGinjector, whose task is to actually inject the GinModule. This injector is instantiated inside a class that implements the interface EntryPoint that, as its name says, will be the entry point of our gadget in the onModuleLoad method. This project has to be run as a Web Application with Google’s App Engine. Figure 5.4: UML Class Diagram, Gadget Deployer Structure The deployer project represented in Figure 5.4 is the project used to generate all the final JavaScript files ready to deploy to a web server with support for gadgets. An intermediate XML file containing JavaScript code is generated with enough logic to figure out which one of the browser and locale configuration has to be served. It is very similar to the tester organization but with two basic differences. First, the GadgetGinModule now binds the class Wave instead of a Wave mock, as it will be running in the whole Wave environment. The other difference is that the EntryPoint, as well as implementing the same interface as before, now also extends the Gadget class, coming from the Gadgets API and representing a gadget. This project needs to be GWT compiled to successfully generate all the files. 24 CHAPTER 5. FRAME FOR DEVELOPMENT OF GADGETS & ROBOTS Gadgets have been tested for deployment using Tomcat as a web server and Shindig as a gadgets server with support for OpenSocial. Several files are generated after GWT compiling, and they should all be put together in the same directory and accessible from outside the own server. Shindig is then deployed as an application inside Tomcat. Shindig needs to be configured accordingly: •First add “wave” to the gadgets.container in the container.js file, in order to support Wave. As Wave does not use security token (OAuth’s authentication token) for gadgets, you have to set Shindig not to require it by adding the following line: ‘‘render_token_required’’ : false,. •Then you have to instruct Wave to use the gadgets server that was configured. The place to do that is a file called server.config in Wave In A Box, and wave-server.properties in Kune. Set the properties gadget_server_hostname to the host running Shindig, and gadget_server_port to the port where it is running. 5.2 Robots Robots were created in Wave with the intention to be able to act exactly as an actual human participant. Revisiting Figure 4.4 we can understand how robots can participate: They are invited to the Wave by inserting their unique identifier equivalent to the identifier of actual participants. They will appear as invited without any apparent indication that they are a robot. Robots can make changes to the wave such as creating a new blip, editing them, changing annotations, among other. In order to be able to interact with Wave it necessary to register the robot Figure 5.5: Robot Registration Screen with the Wave server where the robot will be run. For example, for the Kune node kune.cc, go to http://kune.cc/robot/register/create and you will 25 CHAPTER 5. FRAME FOR DEVELOPMENT OF GADGETS & ROBOTS be prompted with the screen shown in Figure 5.5. As username set the name you wish to give your robot, it should be a free name in the server, as names are unique. In the URL enter the URL where the gadget will be launched, it should be an URL reachable from within the Wave server. After sending the data you will receive a Consumer Token matching the name you entered, and a Consumer Token Secret: a secret key you will need to use to authenticate with OAuth and guarantee the identity of your robot. There is no equivalent to the tester mode from GWT, but running a server for the robots is easy enough so that it is not a hassle. Using Maven plus Jetty in eclipse you can set the Maven goal to jetty:run and the robot will be run. Robots do basically two things: Act when needed, and react to events. Acting means modifying the documents, creating new blips, and more actions. And receiving events means a callback will be made to the robot when something from an external action happens on the Wave. The kind of events that are notified to the robot are the following: •WaveletBlipCreated: Triggered when a new blip is created. •WaveletBlipRemoved: Triggered when a blip is deleted. •WaveletParticipantsChanged: Triggered when a participant is added or removed. •WaveletSelfAdded: Triggered when the own robot is added as a participant. •WaveletSelfRemoved: Triggered when the own robot is removed as a participant. •DocumentChanged: Triggered when the text of a document changes. •AnnotatedTextChanged: Triggered when the annotations of a document change. They are not compulsory but optional, the developer can choose which events will be transmitted. A public file called “capabilities.xml” has to be created in order to notify the Wave server of which events are implemented, 26 CHAPTER 5. FRAME FOR DEVELOPMENT OF GADGETS & ROBOTS and a hash is calculated based on those events to make it easily visible when changes in how the robot acts have been made, because the hash will change. There are other events documented such as GadgetStateChanged or WaveletTagsChanged, which even though available through the Robots API will not be triggered on the server, and therefore never received. 27 Chapter 6 CCWave: A Wave Gadget As it can be seen in the Design Guidelines of the P2Pvalue project, in the Legal Regime section [3], they identify software licenses as a key feature: “We should secure that none of the content produced / uploaded on the platform is infringing: Draft specific terms of use (if we use the Wikipedia model, rather than the Kune model) or include a mention during sign-up process for contributors to accept to release their work/data under a particular license” and state the importance of keeping information free “A large number of respondents described that the commercialization of the commons by third parties would reduce their motivation to contribute. Provide guidance mechanism to help users choose between different licensing schemes based on the interests of the commoners involved in the project”. The default license for any creation of any kind is the restrictive copyright. Copyright tries to ensure that all the rights remain to the original author of the content, but sometimes it can be advantageous to let people freely or semi-freely use, distribute or modify the content [36]. One of the most popular of these licenses, with over 400 million [37] licensed works, are the Creative Commons set of licenses. These are not adequate for licensing software, but in the context of Wave the content is usually creative text work, for which Creative Commons suits perfectly. Thanks to the development of this Gadget, it has been documented in the P2Pvalue wiki’s article regarding Gadget Development the need for an OpenSocial server in order to run Gadgets [38]. 6.1 State of the Art Wave does not have any way of publishing your content under any specific license. Kune has the option for publishing Waves in your personal space 29 Figure 7.5: Pollymer Voters There are three different types of entries in the Wave’s state: •Count of votes: There is one entry of this kind for each decision. To identify which decision this entry is for, the title of the decision is stored as a key. Therefore, the decision titles have to be unique. The value of this entry is the amount of votes that decision has, making it quick to retrieve the amount and show the vote count. •Voters: Again, one entry for each decision and the title of the decision as an unique identifier. The value is a list of all the people that voted for that decision. As the state is only able to store a string, the list is like |[email protected]|[email protected]|[email protected]|. This entry is used to know if a particular user has voted for a decision, and to fill the information inside the votes pop-up. •Title: There is one single entry for each gadget. The value of this entry is the name of the decision to be taken. Used to fill the title after it has been set. 7.3 Conclusions and Future Work This extension is a Gadget meant for voting on a statement, and seeing the opinion of the participants towards that statement. There are already several alternatives for decision making, each one with their unique way of doing things, and there is certainly already one suitable CHAPTER 7. POLLYMER: A WAVE GADGET for every need, and Pollymer doesn’t innovate in almost any aspect. This alternative has limitations though: There is no option for multi-choice answers, no way of editing the title after being created, and the list of votes can get a little uncomfortable to see after a large amount of votes has been made. Multi-choice answers would put this gadget closer to a consensus tool, and being able to block options would make the divergence among opinions more visible. 37 CHAPTER 7. POLLYMER: A WAVE GADGET 38 Chapter 8 AppearWOW: A Wave Gadget Design Guidelines report of the P2P value project claims that “The platform should therefore include tools for collaboration, including key features, such as: Synchronous communication”, among these synchronous tools they mention “Video and voice communication” [3]. Wave is meant for text communication. Text has the advantage that it can be stored easily, searched later and edited simultaneously, but lacks the naturallity of human-to-human interaction. To get as close as possible to it we need voice and video. Then collaborating on text can be made more efficiently. This gadget makes it possible to speak to up to 16 other users and see them. 8.1 State of the Art There is no alternative to video or audio communication integrated on Wave. There is other alternatives though outside of it, some of them shown in Figure 8.1. They focus on video, even hiding text communication to leave more room to the video. AppearWOW can be mixed with text above and below, leaving the video communication as an addition and not the main point. Both video communication tools shown (Google’s Hangouts and Microsoft’s Skype) require you to have a specific user account to use their services, while this gadget lets you join the video communication from within Wave, but also from an external link without giving any kind of personal information. 39 CHAPTER 8. APPEARWOW: A WAVE GADGET Figure 8.1: Hangouts and Skype 8.2 Results To make this gadget it has been essential the use of a pre-existing service called appear.in [41]. They provide the whole video and audio communication based on WebRTC [42], and also facilitate an easy way to use their service in an external website. It is a JavaScript component that can be put inside an iframe, and it will take care of almost everything. Figure 8.3 shows the final result of this integration. When a user inserts the gadget, he will Figure 8.2: Room Selection Screen be prompted with the room selection screen shown in Figure 8.2, letting him choose the identifier of the room people will meet in. The same room can be visited from different waves, and also directly from appear.in, as room names can not be duplicated. It was shown in Figure 5.2 the basic structure of a gadget. The composite is represented by the VideoGadgetMainPanel, the Messages are the class VideoGadgetMessages, and the GinModule is realised by VideoGadgetGinModule. Outside from that, the structure is relatively simple. 40 CHAPTER 8. APPEARWOW: A WAVE GADGET Figure 8.3: Video Conference Gadget As appear.in is a JavaScript service, multiple calls to native JavaScript have been made inside this gadget. The service appear.in uses the name of the room as a unique identifier, so the gadget asks the user for a name before entering the room. The gadget also makes use of appear.in’s ?lite feature, that simplifies the user interface, leaving more space for the images of the video. The camera is accessed through the browser, so no additional software has to be installed. The Wave state in this gadget is really simple, the only thing stored in it is the name of the room to enter it directly if it has already been set. Figure 8.4 shows how the gadget reacts to requests. Once the gadget is inserted, the room selection screen will be shown, allowing any participant to select the name of the room the participants will meet in. When a room is selected, the participants automatically enter the room. If another participant joins the wave once the room has been selected, he will be served the video conference directly. 41 CHAPTER 8. APPEARWOW: A WAVE GADGET Figure 8.4: UML Sequence Diagram, AppearWOW 8.3 Conclusions and Future Work This Wave extension is a Gadget which allows all the participants who are in the wave to join a video conference among them. The fact that this extension is completely dependant on an external closed-source service is a big limitation. The service could stop working at any time, technical improvements on video or audio communication can not be made, limitations like the maximum of 16 online users can not be avoided, the way to use it could change making it necessary to update the gadget, and other changes may arise. To solve all of these problems, an open source alternative for the video and audio communication should be used, or it should be developed from scratch. 42 Chapter 9 Colbotia: A Wave Robot The Design Guidelines for the P2Pvalue project [3] talks about identifying the contributions from users: “The tool should have a way to capture contributions (such as open value accounting) and automatically distribute the monetary gains to the members based on their contribution”. Again, text communications gets in the way of collaboration in some aspects. When working between several people it is sometimes necessary to talk about some aspect of the work they disagree in. In plain text, when there are more than two collaborators, there is no way to know who edited what, so those kind of issues can not be addressed personally. A robot is needed in order to know when and what changes are being made. Thanks to the development of this robot, the P2Pvalue wiki section documenting the Robot Development has been reviewed [43]. The README for the Robot Sample in P2Pvalue has been reviewed [44]. The ´ Robot Registration Process has also been reviewed [45]. 9.1 State of the Art In Wave it is possible to see who has participated in a blip as shown in Figure 9.1, but it is not possible to see exactly what that participant has modified what part of the document. Figure 9.1: Blip Participants in Apache Wave The other thing Wave does to try to keep people informed on when changes happen, is to highlight the changes that just happened and write the author’s 43 CHAPTER 9. COLBOTIA: A WAVE ROBOT name next to it, as shown in Figure 9.2. The problem is it is not permanent, so you only realise of the change if you were already looking at the content being changed. Figure 9.2: Change Highlighting in Apache Wave Also, this extension is heavily inspired in Pads, services like PiratePad, Etherpad, TitanPad and many others, that offer an online collaboration tool that allows to concurrently write plain-text documents. They show a specific colour for each participant to quickly see who edited what. TitanPad in Figure 9.3, even though not the only, has the capability to show a timeline and revisit past states of the Pad, so no information is lost even after being modified. Figure 9.3: TitanPad 9.2 Results This extension, in the shape of a robot, goes around that problem by assigning a colour to each participant, and painting the background of the text 44 CHAPTER 9. COLBOTIA: A WAVE ROBOT that participant edits. The result can be seen in Figure 9.4. It also keeps track of who has each colour and puts it in a blip under the main blip of the wave, as seen in Figure 9.5. It is also possible to get around the colourising of any given blip by starting it with @Robot clear annotations, being “Robot” the actual name of the robot that it was registered with. Figure 9.4: Colbotia Colours The way to make the background of the text be of a specific colour is by changing the annotations of the document. Annotations in Wave are tags affecting a range of text and altering its properties, but they do not affect the text itself. Annotations are also able to be transmitted through the Federation Protocol. Every annotation is defined by a name (Specifying its purpose), a range (Determining the range of characters of text it affects), and a value (The value should that annotation take on that range). There are annotations for text size, links, language, among other. For this robot specifically the annotation style/backgroundColor is the one being set in the changed text. Figure 9.5: Colbotia Tracking Participants 45 10.3 Future Work There is a lot of work that can be done to Wave, and the wave protocol has a big potential. Apache took control of the project, but the development from their part is slow and very conservative, so there is actually a lack of work from part of a big player. The most work is now being done by the P2Pvalue project and Kune, but when pushing changes to the Apache repository, the changes are not always accepted. Wave is in need of features, and some of the ones done here can be considered essential, an they can always be implemented closer to the Wave interface and more familiar regarding the user experience: •Robots: Maybe gadgets and robots are not user-friendly enough. If a user is interested in one of the features a robot can provide, he might not be interested in adding an unknown user to his wave which he wants to keep private. •Gadgets: There is no way of seeing all of the gadgets that are available. If a gadget is not added to the list of gadgets, you need to know the exact URL of the gadget to use it, that means having to know the gadget beforehand. There are, too, many options when trying to choose a gadget, and you need to test them to see if they are the ones needed. When developing the Decision Maker Gadget, because of its slightly complex state storing structure, it was clear that the way of storing state as key-value pairs is too limiting. Storing complex values as strings means you have to create a special format depending on the nature of the object to store, storing lists means having to use a character as a separator of the elements rendering that character unable to be used inside the elements themselves. A good solution for this would be to make a steriliser library that generates XML or JSON documents representing the structure and value of objects, and submits and retrieves values from the Wave’s state in an easy way. 52 Bibliography [1] Google Docs. https://drive.google.com/. [2] Zoho. http://www.zoho.com/. [3] Primavera De Filippi et al, Technical Report D1.3: Guidelines on design settings: Guidelines on institutional design settings, value metrics and value rewards systems, and CBPP software platform features. Public Deliverable, P2Pvalue Project (FP7-ICT-2013-10, 2013-2016, grant #610961), will be available in http://p2pvalue.eu). [4] GNU. Affero General Public License. http://www.gnu.org/licenses/agpl-3.0.html. [5] Google. What happened to iGoogle? https://support.google.com/websearch/answer/2664197. [6] Gina Trapani and Adam Pash. The complete guide to Google Wave. 3ones Inc, 2010. [7] Google. Wave Protocol. http://www.waveprotocol.org/federation. [8] Apache. Apache Wave (Incubating). http://incubator.apache.org/wave/about.html. [9] Google+. https://plus.google.com/. [10] Facebook. Facebook Games. https://www.facebook.com/appcenter/category/games/. [11] Adobe. Flash. http://www.adobe.com/products/flash.html. 53 [12] Oracle. Applets. http://www.oracle.com/technetwork/java/applets-137637.html. [13] uNrEaL. uNrEaL BoT. http://www.unrealbot.com/forum/. [14] Suzanne Vranica. One-Third of Traffic Is Bogus. The Wall Street Journal: online.wsj.com/news/articles/ SB10001424052702304026304579453253860786362, 2014. [15] Kune. http://kune.ourproject.org/. [16] Comunes. http://comunes.org/. [17] Google. Wave Federated Protocol. http://www.waveprotocol.org/protocol/draft-protocol-specs. [18] Peter Saint-Andre. Extensible messaging and presence protocol (xmpp): Core. 2011. RFC 6120 Available at http://tools.ietf.org/html/rfc6120. [19] Torben Weis and Arno Wacker. Federating Websites with the Google Wave Protocol. Internet Computing, IEEE, 15(3):51–58, 2011. [20] Bruce W Perry. Google web toolkit for ajax. ” O’Reilly Media, Inc.”, 2007. [21] Google. Gadgets API. https://developers.google.com/gadgets/. [22] Google. Robots API. http://www.waveprotocol.org/wave-apis/ google-wave-robots-api-overview. [23] Eclipse. http://www.eclipse.org/. [24] OpenJDK. http://openjdk.java.net/. 54 [25] Jetty. http://www.eclipse.org/jetty/. [26] Apache. Tomcat. http://tomcat.apache.org/. [27] Chromium. http://www.chromium.org/. [28] Iceweasel. https://wiki.debian.org/Iceweasel. [29] Apache. Maven. http://maven.apache.org/. [30] Juliana Mitchell-Wong, R Kowalczyk, A Roshelova, B Joy, and H Tsai. Opensocial: From social networks to social ecosystem. In Digital EcoSystems and Technologies Conference, 2007. DEST’07. Inaugural IEEEIES, pages 361–366. IEEE, 2007. [31] Google. Google Wave Federation Architecture White Paper. http://wave-protocol.googlecode.com/hg/whitepapers/ google-wave-architecture/google-wave-architecture.html. [32] Google. Google Wave Federation Protocol Over XMPP. http://wave-protocol.googlecode.com/hg/spec/federation/ wavespec.html. [33] Hans-Erik Eriksson and Magnus Penker. Business modeling with UML. Business Patterns at Work. New York et al, page 17ff, 2000. [34] Martin Fowler. Inversion of control containers and the dependency injection pattern, 2004. Available at https://blog.itu.dk/MMAD-F2013/files/2013/02/ 3-inversion-of-control-containers-and-the-dependency-injection-pattern. pdf. [35] Google. GWT Internationalization. http://www.gwtproject.org/doc/latest/tutorial/i18n.html. 55 [36] David A. Wheeler. Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers!). http://www.dwheeler.com/oss_fs_why.html. Revised as of May 8, 2014. [37] Creative Commons. The Power of Open. 2011. Also available at http://thepowerofopen.org/assets/pdfs/tpoo_ eng.pdf. [38] P2Pvalue Wiki. Gadget Development Tutorial. http://grasia.fdi.ucm.es/p2pvalue/redmine/projects/kune/ wiki/Gadget_Development_Tutorial. [39] Creative Commons License Chooser. https://creativecommons.org/choose/. [40] Antonio Tenorio-Forn´es and Samer Hassan. Towards an Agentsupported Online Assembly: Prototyping a Collaborative DecisionMaking Tool. In COLLA 2014, The Fourth International Conference on Advanced Collaborative Networks, Systems and Applications, 2014. Accepted. [41] appear.in. https://appear.in/. [42] Alan B Johnston and Daniel C Burnett. WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web. Digital Codex LLC, 2012. [43] P2Pvalue Wiki. Robot Development Tutorial. http://grasia.fdi.ucm.es/p2pvalue/redmine/projects/kune/ wiki/Robot_Development_Tutorial. [44] P2Pvalue Repository. Robot Basic Sample README. https://gitorious.org/p2pvalue/waverobotbasicsample/source/ a99e76e234935a2290b881c5e50434e6260ff2d6:. [45] P2Pvalue Redmime. Robot Registration Process. http://grasia.fdi.ucm.es/p2pvalue/redmine/projects/kune/ wiki/Robot_Registration_Proccess. 56 [46] Creative Commons Gadget Repository. https://github.com/End-of-degree-project/ Gadget-Creative-Commons. [47] Decision Maker Gadget Repository. https://github.com/End-of-degree-project/ Gadget-Decision-Maker. [48] Video Conference Gadget Repository. https://github.com/End-of-degree-project/ Gadget-Video-Conference. [49] Robot Colorizer Repository. https://github.com/End-of-degree-project/Robot-Colorizer. [50] Harry Fairhead. JavaScript Is Slow. http://www.i-programmer.info/news/86-browsers/ 3492-javascript-is-slow.html, 2011. 57