 Hello, everyone. Let me start because we are slightly behind schedule. Welcome. My name is Andraj Stimar and I work for Kolabora. Kolabora is the architect and driving force behind putting Libra Office in the cloud. This talk will be about debugging Libra Office online. Libraofe itself is very complicated, but if we put the cloud into the equation, it will be even more complicated, so we will discuss several methods to debug this Libraofe's online application. So the first topic is about the rendering. So behind the scenes there is the concept so-called tile rendering. For the online Libraofe's we render the document into bitmaps, into 268 by 268 PNG tiles, and at the client side we put those tiles together and render the image. But we also have an application, the GTK-tiled viewer, which can be used for debugging rendering issues, so you don't have to set up the complete online environment in order to debug rendering problems. So this GTK-tiled viewer is part of the Libraofe source code. If you build the Libraofe source tree, you will have it. And you can run it with this bin run tool, this shell script, and it will present you the same thing as you would see in the browser. So sometimes there are differences between the rendering of the actual desktop version and the tile rendering, and this GTK-tiled viewer is a useful tool to debug those issues. The next topic is the connectivity problems. So I present here a very simple setup where we have the browser, the user. The browser logs in to a file sharing solution where the files are in the cloud. This file sharing solution will embed Libraofe's online into an iframe, and the Collabora online server will download the file from the file sharing solution, and when we save the file, it will upload it to there. And we communicate with the Collabora online server itself from the iframe to the user browser. So it is obvious that the communication must be bidirectional in all possible directions, and it poses some problems when, for example, Collabora online server is operating on the port 9980, which is sometimes blocked by firewalls, or you can have the Collabora online server behind load balancer, or you can use SSL, and the SSL certificates must work across all possible directions, so we can have problems with self-signed certificates when Collabora online server certificate is not accepted by the file sharing solution, or by the browser. Even you can do SSL offloading at the load balancer, or you can use a reverse proxy to use the standard ports instead of the default port of Collabora online server. So we have a few working and tested solutions that we propose, but users sometimes choose different setups, and sometimes it's very hard to detect where the problems are. So our help here is the built-in web developer's tool in the browser, or we can read the logs of the web server, the load balancer. We should set the logging level to debug, or at worst we can analyze the network traffic with wire shark. Of course we can rely on the lower WSD, the Collabora online web socket demon logs, because it has a very detailed logging capability. So we have eight log levels, fatal, critical, error, warning, notice, information, debug and trace, and you can set this log level in the configuration file, restart the server, and it logs into the system journal, or a separate log file, or even on the console, so whichever is the most convenient. So for the developers maybe it's the easiest to run the thing locally. I collected the information for this on this slide. So when you configure the online component, you enable the debugging, and you give the local LibreOffice pass to run against, probably we want to disable the SSL to make the things a little bit less complicated, and you have to create the cache directory, and then just issue the command make run, and click on the link that is presented on the console, and that's all. So you can read more about this in the readme, in the source code. So when you debug the server part with gdb, you want to add the num respawn switch, and set it to one, so it will spawn only one instance, which will limit the amount of concrete running processes. So also you can export this slip or debugger environment variable, so the processor will wait until you can attach the debugger. And you must note that the binaries use capabilities, so you have to run gdb as root, and it also is running in a CH root environment, where you don't see your LibreOffice installation, so you must simulink your LibreOffice directory into the root, so the gdb can see the LibreOffice. There is another interesting debugging feature in online. So basically we are implementing a protocol, which sends commands such as keystrokes, mouse movements, commands and so on to LibreOffice score, and it sends back ties and status messages. And we can record this traffic, and we save it in a trace file, so you can set it also in the configuration, and later you can replay this trace file with the law stress tool, so it's extremely useful to reproduce the steps and even for creating unit tests. And last but not least, we have a very sophisticated debug mode in the browser, which can be invoked with control shift alt plus d. So let me show you its features. So here I issue the command make run and clicked on the link that was presented, and here I have this hello world document. And now I'm pressing control alt shift d and I have this debugger in the browser. So you can see the ties, and if I start typing, you can see the ties that are requested or invalidated. Also in the bottom left corner of the ties we can see how much time the tile was requested, how many times it was received, and some statistics about the round trip. So the best average and worst update type. Also we can switch on and off these overlays, even the tile overlays, and we can, for example, simulate typing, which is very interesting and very useful when we have multiple browser windows and we can simulate concurrent editing of the same document and see what is happening. So we can optimize better. So you can see that the ties are updated and only those that are actually changed. Even in this debugging mode, if I invoke this web developer tool, we can see the outgoing and incoming protocol messages from the client to the server and from the server to the client in the JavaScript log. So this is yet another level of debugging possibility. It is there if you build with the enable debug switch. I think that's it from me. And if you have questions, please ask.