 Okay, let's get started. Do you hear me? Say yes or no if you hear me? Okay, so I'm Tour Lilpist and I work for Collabora. This talk is about the LibreOffice online server. Some implementation details that might be interesting. So, where do I change the slides? Yes. The goals of LibreOffice online is that you can use any modern web browser that includes web socket support and JavaScript, of course. And the server currently we more or less require Linux, but we don't intentionally use more platform-specific things than necessary at the point. And the protocol between the client and the server is based on web sockets. I don't know how many of you have heard about web sockets, but it's a very simple protocol. Message-based protocol that's full-duplex and runs on top of TCP. And basically what happens is that the client offers a normal HTTP session and then quickly switches to this web socket protocol instead. And there's no way to go back to HTTP. And also one goal in this implementation is to guard against potential security problems in LibreOffice or third-party code. Yes, here's my web socket, as I already said. And that's what we call the LibreOffice online in some places. I don't know how official that term is, but anyway. And the idea is that the processes that serve the clients are relatively isolated from the other process on the system. We use one process per client session and also we try to make sure that client sessions don't have any access to accidentally or intentionally to other client sessions. And of course the LibreOffice code itself also nowadays we use all these testing that was mentioned to make sure that they are reasonably secure and that file formats are securely implemented. The server uses LibreOffice through LibreOffice Kit, which as you might know is this simple C-based API where you can tell LibreOffice Kit to open a document and then render certain parts of it or the parts you want into bitmaps and then you can pass on input to LibreOffice and so on. And there are no separate LibreOffice processes that will be started. All this happens in the same server process that serves one client. Because we all do everything through LibreOffice Kit, we don't use any of LibreOffice's own APIs in the server code. And now you know, which I guess many people would say is a good thing. And as I mentioned, we asked the LibreOffice Kit to render tiles. Tiles are like squares or could in theory be also non-square parts of a document that then the client shows to the user. And the server keeps a cache of this so that if a user later looks at the same document and doesn't do any edits to it, we can just show the same tiles as previously and don't even need to start the separate or start LibreOffice Kit for that user. And that's of course good for performance. Yes, as I said, it's a simple C and also C++ but in the server we used just a C part. This is some of the features of LibreOffice Kit. It can be used to open and save documents and for tile rendering, as mentioned. And also for editing and setting up selections and so on. The using LibreOffice Kit is very simple in the client code. You only include the header file and then when you initialize it, you pass the path name to the directory where the LibreOffice libraries are located. And the same LibreOffice Kit is also used by our Android apps and by this conversion tool. There are some things that are perhaps not ideal in LibreOffice Kit. One thing is that it's a work in progress. There is a stable part of it but that contains stuff that is used by the conversion tool basically, I think. And all the rest is so-called unstable. And whenever new features are added to the LibreOffice Online, we need to extend the LibreOffice Kit and it in many cases also if some things are added to the LibreOffice code. That means that the LibreOffice needs to be a quite fresh version. But that's more or less unavoidable. Of course many of these changes are such that they can be easily backported to the stable branch. They don't have to be master only. And Poco, it's a library that I found when I was looking for a library that would contain this web socket implementation. It's a C++ library that, at least to me, it looked quite clean and usable. It has lots of classes for various things that you might need in all kinds of programs. There is one problem with it that for some reason the newest versions are not available in all distros. Like in Debian for instance they have only, I think it was like a few years old version. And the maintainer of the package doesn't see that interested to package the newest version. And also there is some technical issue but it's not trivial because Poco uses what library was it. I don't remember now, but anyway it's some system library of which it uses its own copy. And it has, because it needs to access some internals in that and of course that doesn't make it easier to package it. Also nowadays with C++11 that we use freely in LibreOffice there is some significant overlap between what Poco offers and what already C++ offers. For instance Poco has its own buffer class that basically is something like STD vector and things like that. So I don't, or we don't use those parts more than necessary than in the online server. And web socket was as I said the main reason why I started looking at Poco because it had it and seemed otherwise also useful. But I then soon noticed that it also has classes for implementing HTTP servers in a quite clean fashion. You don't need very much code to have an HTTP server that like automatically starts a new thread for each client and so on. And handles all the things necessary for that it has its own thread pool thing and what not. And one thing that I noticed that when I use Poco somehow my C++ code looks like Java. But in a way that seemed not like a bad thing but a good thing. And I have been quite happy with it. I don't think it was a mistake to choose to use Poco. Of course maybe somebody could ask why not use LibreOffice's own APIs like all use strings but not in this server also. But I guess that's not a good idea because we want to separate strictly the code that is used through LibreOffice's kit and the server's code. And if we would use the same cell and so on libraries both in the server code and in the LibreOffice code it would be a bit too confusingly mixed. The LibreOffice online protocol it's not like a request response thing but it's supposed to be or it's intended to be like more asynchronous. You can send input to the server from the client as you like and the server can send stuff to the client. Also I mean like spontaneously if it thinks you will need such information. For instance the idea was that the server sends you tiles that it thinks you will ask for soon if it notices that you are at a certain point in the document. It could send you the tiles that are surrounding the ones that you are asking for. The protocol was designed to be human readable. Each message has a first line that is completely in ASCII so you can easily look at some trace and see what's happening. And then after this first line there can be more data. This is currently used only I think for the tiles which are obviously binary. We can have only one document open for client session. That is probably not anything that would need to change. I don't see that at least soon there will be a need to have several documents open in the same session. But on the other hand when collaborative editing is implemented then there can be several clients that effectively use the same session. The tiles are PNG compressed perhaps at some stage we could check if some other compression would be more efficient. But at least for now it's PNG. The security of this is of course of course very important and we rely on this layered model where at the lowest level we have all the security improvements we have done to LibreOffice code itself. And then we use a CH route jail for each session. And because we can't or that requires privileges to use CH route and for that we then use Linux capabilities not set UID route. And we of course immediately drop this capability and we don't need it anymore. And then these servers can be surrounded by some container things like Docker and what not. And that's all I had. The code for LibreOffice Online is at that repository. There are two subdirectories one for this server and one for the client code. And Mihai will talk tomorrow about the client code. And thanks to ISWAP for funding this and if you have some questions please now is the chance to ask them. No questions or Niklas looks like here. Very just stretching your arm. No I don't have any demo available here. Ok, so thank you.