[00:00.000 --> 00:13.120]  Let me start. This talk is partly about the same thing as the previous talk. So, repetition
[00:13.120 --> 00:25.320]  is the matter of invention or matter of what it's called. And here, so, as Balash mentioned,
[00:25.320 --> 00:29.800]  the problem that this is supposed to solve is that if you are editing some document
[00:29.800 --> 00:37.080]  in Kolobara online, and, for instance, on your laptop and then the connection breaks
[00:37.080 --> 00:47.720]  because you are going into a tunnel or something else happens, and then you can just seamlessly
[00:47.720 --> 00:55.120]  eventually it will start using the local voice instead in the browser and the same document
[00:55.120 --> 01:01.240]  that has been downloaded without you knowing into the browser's memory, not to your file
[01:01.240 --> 01:20.400]  system. Yeah, so the solution is that. And, of course, implementing this actually will
[01:20.400 --> 01:30.040]  be quite a problem or quite hard, but we are already working on it and I assume it will
[01:30.040 --> 01:40.680]  be successful. And then when the connection comes up again, you can, or the document will
[01:40.680 --> 01:48.880]  be uploaded to the Kolobara online server and the editing will continue then using the
[01:48.880 --> 01:56.560]  online server. And I'm using the name Kobosm for this or actually it was Thorsten who invented
[01:56.560 --> 02:07.880]  that name, I think. And what we don't think is a solution at least for some customers
[02:07.880 --> 02:15.840]  is to install Kolobara office locally because there are situations where you are not allowed
[02:15.840 --> 02:23.840]  to install third party software very easily and if you did that and wanted to be prepared
[02:23.840 --> 02:30.960]  for this connection in Kolobara online, you would have to keep downloading the document
[02:30.960 --> 02:40.400]  yourself anyway all the time and then start Kolobara office locally separately. And what
[02:40.400 --> 02:51.960]  is WebAssembly? Well, this is what Balazs already told you. One thing that I guess could be
[02:51.960 --> 03:01.920]  mentioned is that this WebAssembly runs in the same sandbox as a web page and it has access
[03:01.920 --> 03:08.320]  to the same things that JavaScript has access to or more importantly doesn't have access
[03:08.360 --> 03:16.560]  to anything that JavaScript doesn't have access to. So it's quite safe, it can't read any random
[03:16.560 --> 03:24.480]  files on your disk and so on. And WebAssembly doesn't even have access to the direct access to the
[03:24.480 --> 03:33.920]  DOM to the HTML page but it can easily run on JavaScript anyway that has access so that's not
[03:33.920 --> 03:42.880]  that important. There are also some environments that are not in the browser. I don't remember
[03:42.880 --> 03:51.200]  but it's called if there's something, well at least one such exists. And WebAssembly is supported in
[03:51.200 --> 04:09.760]  most current browsers, Firefox, Chrome, Safari, Edge. Are there any others? M-scripten tool chain
[04:09.760 --> 04:18.520]  is this clan-based tool chain and I'm not sure if the C and C++ library are like, are they considered
[04:18.560 --> 04:28.080]  part of M-scripten or not? Probably yes. And this C library contains much of normal Linux or
[04:28.080 --> 04:38.720]  POSIX functionality. Also, threading using p-threads and they receive an in-memory file system
[04:39.640 --> 04:49.440]  that you can use to pass files from building the most application into the application at runtime.
[04:49.440 --> 05:03.200]  Some of these very traditional Unix functionalities with oddly implemented, which can be surprising
[05:03.320 --> 05:10.160]  for instance, pipes, which are like 50 years old and have always worked the same way in Unix. In
[05:10.160 --> 05:18.440]  Boston they suddenly are non-blocking, which was a surprise to us. And we use a very specific
[05:18.440 --> 05:27.600]  version of M-scripten. Currently, we could try to upgrade to a newer one. I think it will work also.
[05:28.560 --> 05:37.640]  But selecting what version of M-scripten to use and what tool chain options to use has been quite
[05:37.640 --> 05:46.280]  complicated. There are so many different versions to choose from and they all have slightly different
[05:47.080 --> 05:57.840]  issues or functionality differences. So once you have something that works, you tend to stick to it.
[05:57.840 --> 06:14.040]  And the Kovac application, it contains all the relevant C++ code of LibreOffice code itself and also
[06:14.800 --> 06:23.520]  all the external libraries that LibreOffice uses, plus then the C++ code of LibreOffice, I mean
[06:23.520 --> 06:35.840]  Collabora Online. And then the same JavaScript code as in Collabora Online is also used, of course,
[06:36.640 --> 06:50.120]  and that is what provides the UI. And compared to the typical M-scripten examples, you see if you
[06:50.120 --> 06:59.680]  start reading about M-scripten, in this case, the Bosman code doesn't do any UI itself, but
[06:59.680 --> 07:13.040]  all UI is handled by this JavaScript layer. And the application structure is quite similar to the
[07:13.040 --> 07:21.920]  iOS and Android apps. They are built in quite a similar way, constructed in a similar way.
[07:21.920 --> 07:30.640]  And just like in these apps, instead of having several processes, there is just one process and
[07:30.640 --> 07:45.120]  multiple threads. And here you can see how the Collabora Online is constructed and then
[07:45.120 --> 07:57.800]  comparing. Then they communicate using web sockets. And in Kovac, instead of several processes, we have
[07:57.800 --> 08:06.360]  multiple threads and as such, the message passing between them is more or less the same as in the
[08:07.320 --> 08:22.440]  web-based Collabora Online server. And this is actually something that should be eventually improved. As you
[08:22.440 --> 08:29.240]  see, instead of all this message passing, we could just simply call the function directly that will handle
[08:29.240 --> 08:38.800]  the message eventually. So that should be faster and easier or, let's say, simpler on the system.
[08:45.800 --> 08:54.720]  Here are some pointers how to build this thing. You first compile LibreFix score and then the online
[08:54.720 --> 09:08.280]  dependencies and then online. And if you need to run this through a web server because you can't use these
[09:08.280 --> 09:20.840]  shared array buffers if you load a page from a file URL. And here is a sample screenshot where I actually
[09:20.840 --> 09:34.400]  then disconnected the internet and it's still continued working. And that's it. And thanks to
[09:34.400 --> 09:45.160]  Allotropia for doing this initial work and making LibreFix work as a Wasm application. I'm not sure why I put this
[09:45.160 --> 09:55.440]  thing on this page, but yeah, it was Allotropia who figured out what versions work and so on. So that's all.