BACHELOR THESIS. Application Programming Interface for Native Web Applications. Tobias Widlund

Transcription

1 BACHELOR THESIS Application Programming Interface for Native Web Applications Tobias Widlund Bachelor of Science in Engineering Technology Computer Game Programming Luleå University of Technology Department of Computer Science, Electrical and Space Engineering

2 Application Programming Interface for Native Web Applications Tobias Widlund Luleå University of Technology Dept. of Computer Science Electrical and Space Engineering 21st June 2012

3 ABSTRACT This report describes a project about designing and implementing a usable application programming interface [API] for an existing application that was being ported to a web platform. Today we experience a shift in how we humans work with computers in the sense that everything becomes more and more web oriented. To stay usable, software has to adapt to this and this project is an example on how such adaption may be performed. The application, called Algodoo is an interactive 2D physics simulator written in C++ and as this was ported to the web using Native Client [NaCl], it required new functionality to allow web page elements to interact with it. In other words, an API. It is the design and implementation of this API that is the focus of this report, but within it, the background for the project, will also be explained. ii

4 SAMMANFATTNING Den här rapporten beskriver ett projekt som innefattar design och implementation av ett användbart application programming interface [API] till en existerande applikation som portades till en web-platform. Just nu sker ett skifte i hur vi människor arbetar med datorer på så sätt att allting blir mer och mer web-orienterat. För att fortfarande vara användbar, så måste mjukvara kunna anpassa sig till detta och det här projektet är ett exempel på hur en sådan anpassning kan gå till. Applikationen kallas Algodoo och är en interaktiv tvådimensionell fysiksimulator skriven i C++. Den portades till webben med hjälp av Native Client [NaCl] och behövde ny funktionalitet för att låta element på hemsidor interagera med den. Med andra ord, ett API. Det är designen och implementationen av detta API som den här rapporten kretsar kring, men i den kommer även bakgrunden för det här projektet tas upp. iii

5 PREFACE I found this project interesting and educational for me because I had never worked with designing an API before. I am glad I got the opportunity to do it since it is really useful to know how such things are done. This gives you an ability to make code more reusable and isolated as separate modules that interact with other components. I also found it challenging since I had to work with web development which was a completely new topic for me and I had to rapidly introduce myself to it. I d like to thank Emil Ernerfeldt who was my supervisor at Algoryx for getting me started with the design and implementation through discussions. Tobias Widlund iv

6 CONTENTS Chapter 1 Introduction Background The spreading of the Internet Software adaptation Limitations Current solutions Purpose and goal API details Related work Terms and abbreviations Chapter 2 Materials and methods External tools Website components Native Client Preparation Design Use cases Messaging NaCl side Javascript side Implementation NaCl side Javascript side Chapter 3 Result Results General use Dynamic GUI Chapter 4 Discussion and conclusion Discussion Social, ethical and environmental considerations Future work

7 4.2 Conclusion vi

8 CHAPTER 1 Introduction This chapter serves as an introduction to the project. It will provide information about the background, along with the purpose and goal of the project and also a bit about related work. 1.1 Background The work of this project was done for Algoryx Simulation AB. It was conducted over a period of roughly 8 weeks in the first semester of The work done with them was regarding taking Algodoo, their interactive two dimensional physics simulator to the web. The part of this process that this project concerns was mainly to design and implement the API that was needed to let web elements interact and control the application. This was to provide ways of using Algodoo to create dynamic simulation scenes which behave the way the creators wish, without requiring them to involve themselves in scripting or other technical means to define the behaviour of the scenes The spreading of the Internet The Internet is spreading more and more[1], not only geographically but also culturally[2]. As compared to fifteen years ago, there has been a significant increase in the time spent on the Internet today. Before, one would open the web browser to look up a piece of information or perform another task that was needed at that moment. Today it is not uncommon that people have their browsers open at all time with a myriad of tabs containing various websites and online media. Before this trend of always accessing the web, browsers did not even support tabs[3]. This tendency seems like a natural consequence from the expanding availability of Internet connectivity and speed. When you can always stay online and quickly download media under a fast connection with a relatively low price, the web becomes an excellent asset for finding, saving and sharing data. 1

9 1.1. Background 2 This utilisation is not likely to subside in the near future since there is a lot of progress to be made in terms of the availiblity of the Internet around the world. Instead, we may see an increase in the spread of the Internet Software adaptation The current extensive use of Internet as a media platform definitely has its implication on software development. The classic view on most software is that networking is an optional component that is not necessary unless the software is specifically targeting networking related topics. Software came as an offline application. It was installed on specific machines and resided on the hard drive to be used when needed. Using the same software on another machine typically meant that a clone of the application would have to be installed. In this new age where the Internet is more capable, it is common to see software using this as a resource to become more available. Instead of software being installed on specific computers, it can be easily distributed to a wide set of users by setting it up as a web service. People can use it by simply accessing a web URL. The software will temporarily download and run without needing any installation and it can be visited at any time. An example of such a service is the online photo editor by pixlr.com[4]. With solutions like cloud computing or peer-to-peer distribution, data can easily reach a vast amount of users Limitations The approach of having software as web-based applications is different to the classic approach. The web environment is in many ways much more restrictive on the developers. This is apparent with the issue of security. Running an application from the web is as easy as opening a URL of which the source could be anything. Without security restrictions, the user s computer would be very vulnerable to malware and attempts to compromise vital information. These security restrictions are often simply implementations that prevent the developer from using features that could be a threat. For example access to the file system on the harddrive, or the ability to execute code from external sources are typical things that would be blocked. Another limiting factor is the one of data retrieval. With an offline application the data is often shipped along with the product, written in files that are stored where the program can access it. This is often not the case with online applications. It can either be downloaded with the application on every access of the page, or it can be downloaded once and stored for reuse when visiting the site again. Depending on which approach the application is using, implementing data loading can be less trivial than with offline applications. Compatibility can also be a problem. With online applications there is always a channel through which the application is presented to the user. That channel is the browser.

10 1.1. Background 3 There are various of platforms on different kinds of devices and these often have different browsers. Many platforms also have more than one browser. The browsers implementation of the tools that was used to deploy the application might differ and compatibility is a common issue. Due to this, developers have to keep the various platforms in mind when they are developing the applications. The final limitation of web-based application development that this report will talk about is the problem with tool chains. Today s software development has a history of offline development that stretches years back. The program languages and tools for developing and deploying offline applications are mostly adapted for making such, and using those to create applications that can easily reside on, and launch from a website is not practically possible. Web development typically requires ways to interact with the homepage itself for its desired functionality. This means communicating with other languages commonly used on the web such as HTML[5], Javascript[6], CSS[7], etc. It also implies the ability for an application to launch itself as a webpage component so that it can be integrated with the site itself seamlessly and these have not been trivial to solve Current solutions This approach of web development is still quite new and upcoming, and therefore there are currently not many solutions to these problems. Even so, there are still a few attempts to bring more performance demanding and application oriented software to the web. None of these have as of yet become widely used standards and hence the support over different platforms and browsers is still quite poor. An exception to this is the Adobe Flash multimedia platform which has been widely used for years to create interactive applications on the web[8]. However, the performance is poor compared to offline applications. Other solutions include Microsoft Silverlight[9], Unity[10], WebGL[11] and recently also WebCL[12] which all aims to aid the creation of various web based applications. The solution that this report focusses on is Google s Native Client. It is a framework for lifting native code to the web. It allows the developer to compile C/C++ code and run it sandboxed on a site. It supports rendering with OpenGL ES 2.0 and is capable of handling input such as mouse, keyboard or gamepad events from the user. It integrates with websites by acting as a module that the website can communicate with through the Pepper API using Javascript. The reason why this solution was chosen was because it was the platform that Algodoo was being ported to and hence the environment that was worked with and therefore the one of interest to this report.

11 1.2. Purpose and goal Purpose and goal The goal of this project was to design and implement an API as a part of the process of taking Algodoo, an interactive two dimensional physics simulator, to the web. At the start of this project, Algodoo was already under the process of being ported to NaCl (Native Client). As an application taken to the web, it needed a way to let the hosting website communicate with it. This was to enable functionality, such as dynamic GUI design to manipulate and monitor physics simulations. This form of communication was to be done through the API and that was the goal of this project. Since Algodoo focusses on education, the API was meant to provide functionality that simplifies such usage API details The API was meant to be able to handle two main situations, with the first one being to give the user an ability to control Algodoo exernally via elements on a website. This includes providing the website developers access to any feature from Algodoo that is likely that they would want to add to a web instance. For instance, the ability to play and pause simulations, drag and manipulate bodies as well as create new ones are obvious features that had to be possible. Less obvious features that are still important to give dynamicity to how it should behave, include being able to inspect data of the simulation in real time. This can be useful for displaying physics data or plotting it into graphs to, in an educational sense prove a physics concept for a user. The second situation was for non-technical users that want to construct a simulation scene with a specific purpose to have on a simple website. These users should not have to know about web development or read the API specifications to create something that suits their needs. The idea was that the API should provide automatic handling of simple GUI components that can be selected by the user on the page in real time. 1.3 Related work Native Client as a development platform is still relatively new with version 1.0 of the SDK being released no later than October 2011[13]. Therefore the amount of work is not in abundance. Despite this, there have been several efforts made that are both academic in nature and those which are not[14]. The academic efforts to investigate the capabilities of NaCl include two papers. The first one, called Native Client: A Sandbox for Portable, Untrusted x86 Native Code [15] focusses on describing Native Client as a sandboxed platform for running native code and talks about the security and implementation. The second paper, Language-Independent Sandboxing of Just-In-Time Compilation and Self-Modifying Code [16] also talks about the sandboxing performed by NaCl and security in relation to compiling software on the fly and code modification as attempts to break security.

12 1.3. Related work 5 There are currently ongoing research projects that are using or working on Native Client in some way. A project called Extending Google s Native Client with Information Flow Control [17] aims ta enhancing NaCl by in a controlled way permitting filesystem and networking access. Secondly, the project GoNative [18] wants to enable execution of native code safely in various programming languages, and they worked on RockSalt, a machine-code verifier for NaCl. A formal correctness proof of the sandbox capabilities of NaCl was performed by the project FPdNaCl [19]. The last project mentioned here is Lind: Secure Lightweight Cloud Computing [20]. It aims to create a cloud computing environment which would expand NaCl s capabilities to access data. Various non-academic projects regarding porting software to NaCl exists as well and Google has published information about some of these. For instance, the Multiple Arcade Machine Emulator, or MAME for short, has been ported by Google and took the opportunity to post the information as a case study on their website[21]. In a similar fashion, Google also ported XaoS which is an interactive graphical exploration tool for fractals, to Native Client. This work was also published on their website as a case study[22].

13 1.4. Terms and abbreviations Terms and abbreviations NaCl - Google s Native Client API - Application Programming Interface URL - Uniform Resource Locator HTML - HyperText Markup Language CSS - Cascading Style Sheet OpenGL - Open Graphics Library GUI - Graphical User Interface SDK - Software Development Kit JSON - JavaScript Object Notation JQuery - JavaScript helper library for uniform GUIs and simplicity

14 CHAPTER 2 Materials and methods This chapter is dedicated to thoroughly explaining the methods used for this project. It will start by going through the technologies and tools that were used. Then the chapter will continue by describing the thoughts that were put into the design of the API and finally it will talk about the implementation of it. 2.1 External tools Various external tools were used in the implementation of the Algodoo web API. These were crucial for the web deployment of Algodoo. It was through these that the application became launchable on the web and could be embedded as a website application. Since these tools were already used for the application foundation, it was practical and obvious to use them for the API too Website components In the case where there is an application deployed on a website, there are two parts that are cooperating to deliver the full experience to the user. Aside from the application itself, there is also the website that displays it. The cooperation between these two parts may range from the case where the website is merely a blank page used to load the application, to when the website provides controllers to influence the application or ways to actively monitor it for information. In the following parts, the website components that are relevant for this project will be declared. HTML HTML (HyperText Markup Language) is a widely used markup language to define the contents of a website[5]. The role of HTML in this project was that it was used to make up the page on which Algodoo is displayed. It holds the frame which contains the render 7

15 2.1. External tools 8 window and is capable of providing informative text or links that can be displayed next to the application. Javascript A large part of the code written for the API was written in Javascript. Javascript is a scripting language that adds an ability for web content to have more interaction[23]. The script can be executed depending on input from the user. For instance, a snippet of Javascript that changes the title of the website can be executed when the user clicks a button. A way to interact like this is crucial to have any kind of dynamic content since websites that do not handle user interaction would only display static data. The Javascript part of the API takes care of managing the GUI part and provides the user with a means to influence Algodoo interactively and also to inspect it and find out information about the current simulation state. Messages are constructed and passed on to Algodoo as strings as a way to communicate Native Client Google s Native Client technology had a huge part in this project. It is a novel attempt by Google to create a technology capable of running performance heavy applications in a browser displayed on a website. NaCl does this by running native code (at this point in time only C/C++ but further language support is planned) in a double sandboxed mode. The sandboxing is for making sure that the applications are not executing any malicious code that would damage the system. Due to this, the applications do not have direct access to the files on the computer or the hardware itself. It also has a strict defined way of allowing communication between the website and the application. This is done through the Pepper API. Native client is an open technology and could theoretically be supported by any browser that implements the standard, but so far it is only usable with Google s own browser Chrome. NaCl SDK NaCl comes with a downloadable SDK (software development kit) that is required to compile applications for Native Client. The SDK includes a modified gcc toolchain that is capable of compiling C/C++ code to both 32-bit and 64-bit executables that can run natively on the web. It also comes with tools that can be used to install various versions of the Pepper API as well as examples to show how to work with the SDK. The Pepper API The NaCl SDK comes with the Pepper API, which acts a bridge. It is what allows NaCl applications to communicate and pass data to the Javascript side of the system. Without

16 2.2. Preparation 9 it, the applications would be completely isolated. Data passed between the components are always sent as text strings. This means that all data has to be serialised on one side and deserialised on the other to be able to be used. In practice, the sending works by calling a function on the sending side with the text string as a parameter. A corresponding function on the other side will be called when the message can be handled. The received message is passed as the first parameter to the receiving function. The Pepper API also provides an ability to catch input events from the mouse and keyboard. Furthermore, it creates and manages an OpenGL context for the application. This makes it possible to render hardware accelerated graphics. All data communication between the website side and the application side is asynchronous. In practice, this means that either side never waits for the other. When a message is sent from one side, it continues to execute the code and does not wait for a response. The sender can therefore not assume that the message was received on the other side since the receiver might be busy computing or otherwise be in a locked state. Another consequence from the fact that the sender cannot expect a reply instantaneously is that requesting data is not as trivial. The standard procedure would be that when some specific data is interesting, the application would call a function that directly returns that data and it can directly use it for further computation. However with asynchronous communication there can never be a function that directly returns data between the sides. The reason why the Pepper API is built around this princible is stability. If either side never waits, they can never freeze or get stuck waiting for the other side which would severely impact the user experience when visiting the site. 2.2 Preparation The first stage of the preparation was spent getting familiar with both NaCl and general web development concepts due to prior inexperience. This time was spent researching and learning the principles that would be needed to be able to implement the API. The first thing that was done was to read the introduction material and documentation about Google s Native Client and two mini applications that changed colour of a square were implemented. They were displayed using an OpenGL canvas in real time. The first used a separate thread for its logic, and the second one used a technique based on scheduling. The way in which NaCl applications communicate with the website using messages was also investigated. 2.3 Design After a basic understanding about how interaction between the systems has to look was achieved, work proceeded to the API design. The goal was to not get stuck with perfecting the design since it would be too time consuming. On the other hand, starting

17 2.3. Design 10 to work without a proper design is not desirable, since it could result in an insufficient design that would later on require heavy expanding or reworking. This could be more cumbersome and more time consuming due to the fact that lots of work would have to be redone. A use case is a thought up situation which aims to expose the requirements of a particular system. In this project, the purpose of having use cases was to from these later on be able to deduce an API design which would be functional enough to meet the needs whilst at the same time being simple enough to be usable for the target group of people Use cases The use cases were decided by discussions with other people at Algoryx to make sure that the API followed their vision of how Algodoo should be as a web application. Ultimately, two different kinds of use cases were decided upon. Case one - General use The first case involved giving the users of the API an ability to tie website elements to the general functionality of Algodoo. This included being able to set and get values of Algodoo. Examples of values that should be possible to be exchanged are general global values such as the current state of the simulation (playing or stopped), physics related variables (gravity strength, air resistance, etc) and also entity specific attributes like friction, material type, texture, density etc. Manipulating and viewing values alone is not enough to give the user enough capabilities though. It was decided that a system for event subscription was needed as well. What this implies is a system that listens for events that might happen inside the Algodoo application. These events may from the API side be subscribed to, and in the case of the events being triggered, the web site part of the system will be notified with a message containing information about the event so that the user can decide what will happen. Using a system of subscription is preferred since all kinds of events will happen very often and transferring all events without knowing if they ought to be handled is very unnecessary and by letting the user decide which particular events to subscribe to, the system will ensure a minimal transfer amount of data. By providing ability to set and get simulation data and subscribe to particular events, the user has good capabilities of designing many different websites around the application in a free and yet powerful way. Case two - Mini demonstrations The second use case was aimed for the less technically adept users who desired to use the API in a simple manner. The part of the API depicted in the previous section about the general use case would require at least basic knowledge about HTML and Javascript

18 2.3. Design 11 to be used. Even though the requirements would not be high, for the average user who does not know anything about web development, it is still a big step to learn the basics of HTML and Javascript just to be able to use the Algodoo API. Although at the same time it is something that is difficult to avoid since the API itself is written in Javascript. Since there would be a large portion of the users that would only want to make simple demonstrations without involving themselves in the technical aspects of the API, it was decided that an extension to the general API should be implemented. This extension should take care of simplifying the usage for users that want to only create simple physics demonstrations and put them in embedded frames on their sites. An example of when this is desired is when teachers want to show a principle of physics with a simple scene. In many cases it would be enough to position the physics bodies in the scene and attach observing elements or controlling elements to them. For instance, a simple demonstration could show how friction of an object with a flat underside, lying on a sloped plane would affect the sliding behaviour or the object. The user would, using a graphical interface, place a sloped plane, draw the flat physics body, and through the interface generate and attach a simple slider to the friction attribute of the physics body. By the same simple means, the user would be able to specify if the scene should have a play and pause button and if it should be possible to interact with the scene. By using straight forward graphical ways to provide functionality to the user, it would be very accessible to just about everyone. The API should also be able to give out a link to the user when done so that the user can embed the simulation scene on any other website. By having these two cases, one providing general functionality and the other providing easy ways to do general things, the API would be very flexible and the usage capabilities would ultimately depend on the effort that the user choose to put into designing scenes. Users that only want to demonstrate simple things would be able to do so without effort whilst users wanting to invent websites with advanced interaction with Algodoo would not be hindered Messaging To enable communication, a system of passing messages was chosen. All messages passed between the website side and the application side was of the String data type. In other words, plain text. Due to this, the format JSON was used. With JSON, all data are expressed as strings and since Javascript has native JSON parsing, this seemed like an obvious choice for clarity and simplicity NaCl side The Native Client side of the API is the side that has to directly interact with the Algodoo application. In fact, it was implemented to be part of the Algodoo executable file. This part is responsible for two things. Firstly, receiving and handling messages from the Javascript side, and secondly, subscribing to and catching events occurring in

19 2.4. Implementation 12 Algodoo upon which a corresponding message is constructed and sent to the Javascript side Javascript side Since the website side according to NaCl has to be written in Javascript, this is the language that the other side of the API had to be written in. This is the only part of the API that the users ever interacts with since the NaCl side is all taken care of internally. Hence, the tasks that this part has to manage are the ones related to user interaction. Since it is written in Javascript, the ways that interaction could be implemented on the final websites would be limited only by what interaction possibilities that Javascript offers. Based upon the two different use cases listed above, it was decided to have the Javascript side in two parts. The first part would act as the core of the API and would be the direct bridge to the NaCl application and it would be this piece of code that calls the actual function to post a message to the NaCl module. Outwards, it should present access points that can be used to subscribe to specific events or attribute changes. Separated from the first part, the second part should act like an extension to the first part in the way that it simplifies its usage. It would be the part that is responsible for making it easy to create quick GUIs for a scene dynamically without having to write a single line of code. It should utilise the functionality of the core part to build upon it and extend it by providing functions for GUI creation. 2.4 Implementation The implementation was done using the modified g++ toolchain that comes with the NaCl SDK and version 18 of the Pepper API was used. A laptop with Ubuntu was the machine which was used for the coding. The implementation was prepared by looking at the use cases, structuring them and plan them out in detail as if they were verbose descriptions of the real applications. These details was looked through to find the lowest requirement of the API so that it was apparent what functionality that should be aimed for to have an acceptable prototype. Using this approach, it was possible to deduce which functions of the API that would be good to start with with relative ease NaCl side To provide the API with the back-end it would need to access information and be able to manipulate the NaCl module, work was initiated on the NaCl side. In a sense the functionality on the NaCl side can be seen as an API for the Javascript side to use to interact with the application. The implementation of this part was done in C++ since

20 2.4. Implementation 13 that was the programming language in which Algodoo was written. It consists of a number of classes with specific functionality dedicated to bridge data between Algodoo and other systems. The two most important ones of these classed will be listed since the rest are merely helper classed. Message bus For the NaCl module to be able to react to and respond to the calls of the website, there has to be an entry point for the messages that are passed over. In this implementation, such an entry point is defined in the message bus class. Its purpose is to receive messages from the Javascript side and analyse them to deduce what actions should be taken to properly serve the message instructions. When the message bus receives a message, it runs it through a JSON parser to be able to investigate the data. For this project, the JSON parser from the C++ extension library BOOST was used due to BOOST already being integrated and used elsewhere in Algodoo. The message bus is capable of receiving two kinds of messages; subscription messages and command messages. Subscription messages are the mechanism Javascript uses to request for information. These messages contain a string defining which attribute or event that should be subscribed to, and from this information, the message bus tells the subscriptor class to catch those events when they occur in the application. The command messages contains information about an attribute that should be set, and what value it should be set to. These are handled by the message bus so that a proper thyme command (thyme is the internal scripting language of Algodoo) is constructed that would set the proper attribute. After that, the command is run. Attributes that could be set for instance are gravity strength, if the scene is running, or friction on a specific object. Subscriptor As previously noted, the sending of information is based on subscription. This is because in a typical physics simulation in the Algodoo application, there are lots of things happening at once. If all this information would be sent, the message bridge would be flooded. Since almost none of the information would actually be used, it is very unnecessary. Therefore the subscriptor class was implemented which acts as a filter for these events. By default it passes on nothing, and through the methods of this class, events can be registered for subscription. There are four types of event types that can be subscribed for. These types are based on if they are global or object specific, and if they are general events or events regarding if an attribute has changed. In other words, the four types are: global general events, global attribute changes, object specific general events or object specific attribute changes. The reason why they were split into these four types is that global and object specific events are handled different in the sense that object specific events need an object ID parameter. For attribute changes as compared to general events, the reason for the split was that a

21 2.4. Implementation 14 very large portion of the events will be attribute changes and all of these can be grouped together and handled in the same way aside from the single parameter of which attribute they address. That way, handling of those events became much simpler. To subscribe for an event, there are four different methods that can be called where each one of them corresponds to one of the four event types. The parameters are specific to each function. When any of those functions are called, the subscriptor registers the subscription and registers callback functions in the existing event system of Algodoo. When this is done, the subscriptor will automatically catch the event occurrences and construct proper JSON messages which are then directly stored in a message queue that is emptied and sent off to the Javascript side at the end of each frame. Attribute schema The attributes do not always share the same properties or usages and in that sense they are different and need specialisation when handled. This specialisation is defined in an attribute schema which is a list of all possible attributes and their unique properties. The data is saved as JSON in the subscriptor class and upon initialisation of the system, the schema is sent to and kept by the Javascript side. Every attribute in the schema has various fields describing its properties. Some examples are default element type, minimum and maximum value, and data type. This schema is used by the subscriptor when it is reading or writing to the attributes to know how it should handle them. It is also used on the Javascript side and it will be described later on in this chapter Javascript side This side, which is the side that the website may interact with was written entirely in Javascript since messages from NaCl modules to the website are received using a Javascript function and the API is built around this function. Both the core of the API that interacts with the NaCl side and the extension part providing dynamic GUI creation are kept in the same file. The extension part is using the free Javascript library JQuery, which not only eases the process of manipulating websites but also makes it possible to create uniform GUI elements throughout every browser. API core The core of the API is the central part which directly surrounds the functions for both posting messages to the NaCl module and receiving messages from it. Only a few selected features are implemented by the core. This is to keep the core functionality simple but yet powerful. When the core is left simple providing only the basic capabilities, the users are allowed to themselves construct complexity if they wish and that way they are given much more control. The implemented features include subscribing to both general events and events regarding attribute changes as well as reading or writing the attributes.

22 2.4. Implementation 15 Due to the asynchronous communication between the NaCl module and the Javascript side, attributes have to be handled in a special way. It is important that the user can read the attributes that are interesting at any point. This is a problem due to the asynchronous nature of how messages are sent. Since you cannot wait for the NaCl module to give a response, you can not send a request, wait for an answer and display it, as would be the standard approach with a function returning something. What was done in this project was a form of attribute mirroring. The core keeps a hash map that is able to store attributes. If the user wants to be able to read an attribute, a function to observe that attribute must be called. This function sends a message to Algodoo and tells it to subscribe for that attribute, after which it creates a local mirror of the attribute and stores it in the map. Whenever the attribute is changed after that, the Javascript side is notified and updates the mirror accordingly. When the user calls the function for reading the attribute, the local mirror is read. That way the pitfall of the asynchronous communication is avoided. Writing attributes is a simple matter. The function for this just sends a write message to the NaCl module to have it change the internal attribute. This also triggers the attribute changed event mechanism, causing it to pass a notification back to the Javascript side so that the mirror attribute can be updated and possible callbacks be called. The functions that let the user subscribe for events also accept two extra parameters aside from the one telling which attribute to subscribe to. The first is which Javascript function should act as a callback when the event is detected, and the second one is a user defined parameter that can be used for any data to give more capabilities. Dynamic API More functionality which is made to be appealing for the non-technical user is made available with the extension part of the API. It provides the capability of generating custom GUIs for individual simulation scenes on the fly. The code that implements this part never calls the raw message sending function. It only communicates with the API core, adding a level of functionality on top of it. The dynamically added components are implemented using the JQuery Javascript library. This library was chosen since there are no simple way of creating uniform GUI components using bare Javascript. Sliders are not implemented the same way across different browsers for instance. In one browser it might appear as a slider on the page whilst it might appear as a drop down list in another. This would make the GUI system very inconsistent and difficult to control. There are four different elements that can be generated and these are text labels, sliders, input boxes and toggle buttons. The elements are always tied to either a global attribute or an object attribute which they directly represent in the sense that if either the attribute they represent or the element itself changes, the other one changes accordingly. Elements can be generated by calling factory functions. There is one function per element type and the attribute it should link to is supplied along with the object ID if it is an object

23 2.4. Implementation 16 attribute. These functions uses the subscription and callback registering capabilities of the core API to subscribe to the attribute and supply a function to update the element upon change as a callback. The elements are customised depending on the attribute which is supplied so that for instance, proper minimum and maximum limits are set up for the sliders. This information is fetched from the JSON schema mentioned earlier describing the attributes. Finally there is a function which fetches the information about the supplied attribute, compares it to the JSON schema and decides through the attribute field describing the default element type which type of element should be used. Internally it uses the previous factory functions to construct the elements.

24 CHAPTER 3 Result In this section of the report, the result that was produced throughout the project will be presented. The section will be ended by talking about future work that can be done to improve the project and how it could possibly end up being used. 3.1 Results The results of the project is an expandable API framework for the interactive 2D physics simulator Algodoo. As planned, the resulting API has both a part that lets the user have more detailed control over how Algodoo and the website will interact and the part that allows the user to with the help of some clicking, dynamically add GUI elements that controls or monitors specific features of a simulation scene General use A user that uses the API to have more precise control over Algodoo is able to through a few functions notify Algodoo which events to pass over to the Javascript side so that the user can handle them in a way he or she pleases. Since the user by that principle has access to all interesting event occurrences and the related information about them and furthermore can utilise Javascript to respond to them in a useful way. This creates a powerful way to work with Algodoo as a web application and to tailor the way it is integrated with websites of differing purposes Dynamic GUI The dynamic GUI part of the API was designed with simplicity and ease of use in mind so the users of this feature do not need to be able to program, or even see a single line of code. The implementing websites defines how the GUI elements are requested. A test application was written that implements buttons and text fields that are used to 17

25 3.1. Results 18 generate the elements but when the API is attached to Algodoo, it is supposed to receive commands from the Algodoo interface itself, so that users can for instance right click an object in Algodoo to mark one of its attributes for observation, and the API will generate an appropriate element. Figure 3.1: Screenshot of a test NaCl application using the API to control various attributes such as the colours of the canvas. The GUI elements seen have been generated on the fly using the functionality of the API. As seen in Figure 3.1, the dynamically generated components are added below each other sequentially. They were added only by entering the name of the attribute into a text field and clicking a button which then calls a function in the API for generating an element with that attribute name as a parameter. The API uses the JSON attribute schema to decide which element fits best to the given attribute, after which it generates the element and sets the properties also according to the schema. Then the newly created is added to the end of the dynamic GUI container of the page and are directly linked to the internal attribute they represent. Any change of the internal value will manifest itself in the GUI components, and vice versa.

26 CHAPTER 4 Discussion and conclusion 4.1 Discussion The first issue that was confronted was the one of previous inexperience with Javascript and web development in general, with nothing more than the very basic concepts known. To be able to write the Javascript side of the API, time had to be spent on learning a significant amount of web development and Javascript. NaCl was also a new concept that was a requirement to know about for knowing how to design the communication between the NaCl module and the website and therefore most of the time during the first week and a half was spent to research and learn about these concepts. Another issue was that the computer that was used for the project at Algoryx had the Linux operating system installed and at the point in time when the project was started, Algodoo had a few issues with compiling for Linux. Therefore a few days were used to solve these issues so that the application could be properly inspected aside with the source code to know how the event subscription system would be implemented. One consistent problem that made progress a bit slower overall was that Algoryx process of porting Algodoo to NaCl took much longer time than they had planned and there was no running NaCl version of Algodoo until the very last week of the project. Therefore there were no opportunity to tie the API to the application itself and the work on the API could only be tested and verified using a quickly implemented NaCl testing application. Although this application worked for its purpose, it was still a hinder to not directly work against what the API was intended for. The goal was to create an API for Algodoo and even though it was never yet connected to Algodoo, the project was still a success since the API in itself is fully implemented. To implement the API for Algodoo is a trivial task and the conclusions drawn in this report are not dependent on that last step. 19

27 4.1. Discussion Social, ethical and environmental considerations Whilst this work does not possess any noteworthy relevance to environmental questions, it does have ethical questions and social aspects that are of indirect relevance to society in general. The concept of web distributed software is as previously stated tightly related to solving security issues. This is an ethical question in the sense that if it would not be considered and solved by the software makers, the users could unknowingly be exposed to security threats. In this project however, there was no need to solve these problems due to the fact that NaCl solves it already through the method of sandboxing as talked about earlier in the report. The spreading of Internet which was talked about in the first chapter of this report affects society a lot since it changes many people s habits and ways how they do things. For instance, in this age it is possible to look up street addresses, phone numbers, share pictures video and other media without effort all with the help of portable Internet connected devices. For these devices to function, they need rely on web based software and thus the ability to take software to the web platform is crucial for the whole process. Creating an API for a NaCl application does not directly affect the process of developing easier ways to port software to the web, but it affects indirectly by being a part of the process. It can be seen as a way to investigate the potential of Google s Native Client technology and this work can give an insight in what it is capable of and how efficient the workflow is which are aspects that are definitely relevant for potential future projects using NaCl Future work There are still things that can be done to improve the results presented in this report. The most obvious thing is to connect the API to the target application, Algodoo, as it is now only implemented for the test application. This is however not much work and would only be a matter of specifying the attributes in the JSON schema and then bind the subscriptor class to proper callbacks in the application to be able to catch events and Algodoo already has a system for callbacks. The amount of available GUI elements could also be increased. This would not be something that would be finished at a set point, but more something that would expand by the need for it. Something that could prove to be useful for instance is a set of GUI elements that would allow simple data plotting to graphs. In practice, this could mean an ability to effortlessly mark an attribute (such as the velocity of a simulated body) to be plotted and displayed in real-time. Finally a crucial feature that would be needed to really utilise the potential of the dynamic GUI system would be a way to share customised Algodoo simulation scenes over the web with ease. A suggestion on a solution to this would be to implement a mechanism that saves the currently added GUI elements to a file that is uploaded to

28 4.2. Conclusion 21 Algobox (a cloud server held by Algoryx for sharing Algodoo scenes with other Algodoo users) and given an ID. The API should then also be given functionality that with a simple call of a function generates a link ready to be embedded on other websites, containing parameters that points to both the current scene and the current set of GUI elements, both residing on the Algobox server. Users could then quickly and easily create many different mini physics simulating scenes with custom behaviour and share it on any site with a simple HTML embed tag. 4.2 Conclusion After this project it is clear that NaCl works as a way of taking existing applications written in C or C++ to the web. The concept of how the applications communicate with the website is simple yet effective and added no issues to overcome when designing the API. Since it was only communicating through one function it is trivial to isolate it as a separate module and have it embedded and integrated with other modern web technologies. A problem with it as a web platform is that of compatibility as only Google s browser Chrome can run it currently. However since the progression towards a more web-oriented paradigm is still ongoing and not standardised, it is hard to tell if Google s Native Client initiative will ultimately stay or of it will be shadowed by better alternatives in the future and such it is difficult to say if it is the perfect solution even though it currently is one that definitely works.