 Hello everyone. So today I will be speaking about one and our work on the AGM project. So my name is Roger. I'm from Igalia. We are an open-source company, a consultancy company. We have around 140 engineers around the globe. My team specializes in web rendering and multiple web engines like Chromium WebKit, WPE and Firefox. And we also have teams working on compilers and graphics, multimedia and the Linux kernel. We have a wide range of contributions to open-source projects. We are the second main contributor to Chromium after Google and to WebKit after Apple. And I added a few links for reference for the previous presentations about this topic. We have an ongoing effort of changing how one works on IGL. And these previous talks explain a bit how one works. I will be getting into that in a bit. And why we did this effort. So I was going to make a live demo, but I have connectivity issues on my QMU setup. So I'm going to fire up a recording of our first proof of concept of CEF working on one. So for those of you who never heard about one and the work we do on IGL, one stands for Web Application Manager. It's a runtime created by LG for enabling developers to create web applications around them on embedded devices. And everything that you see here is a web application, the left side panel and the middle panel. And this is already running on CEF. And if you're curious about how the applications work, you can go to the automotive grade Linux Garrett and search for HTML5 on the projects and you get a list of all the applications that we have on this demo. And I included information about how to build the demo image for web applications because I think most of the crowd for this conference never saw the previous presentations. So this is only a reference. And okay, I will speak a bit about what one is and how it works. So like I said, it was a runtime created by LG for shipping web applications to several devices. And we adapted this runtime to work on the IGL project. It's not framework specific. You can basically do work with any web application framework. If it works on client side, you will be able to deploy it to the embedded devices and it will work just fine. It was built on top of the Chromium web OS that was also maintained by LG. The main responsibility of the runtime is managing application lifecycle. And it has a lot of optimization on top of the regular Chromium implementation like monitoring status of the application and memory consumption and CPU consumption. And as you can see, one leverages from the content layer from Chromium and it provides an API for creating browser processes and web pages and a way of web applications to communicate to each other. The AGL implementation is a bit different from this, but this is the original from web OS. In our case, we don't use LUNA, we use GRPC for IPC, but the rest was pretty much the same. And I was only explaining how one worked to talk about the work that we've been doing in this last year that was replacing part of part of one to not use Chromium web OS anymore and instead using CEF. And I'll explain why we did it and how it's working right now. And here we have a few reference links if you want to learn more about CEF architecture and some applications that are using it and a link to the project. So CEF is an open source project that follows pretty regularly the Chromium release lifecycle. They are usually a week behind Chromium releases and Chromium releases happen very often. They happen bi-weekly and CEF is basically a collection of scripts and patches that are applied on top of Chromium. It adds itself to Chromium 3 actually and it creates a few new build targets to generate the Libcf and the sandbox executable. And the Libcf is a stable API that can be used for basically the same that was done by Chromium web OS before. CEF has its own backend. They call it runtimes. There's the alloy runtime that's a runtime based on Chromium contents layer and this is a layer that has an API for anyone that wants to implement a browser but doesn't contain the very opinionated implementations that Chromium uses. So it's a generic way of providing an API for making a browser. And there's also the Chromium runtime and the Chromium runtime is based on the Chrome layer that contains all the Google implementations for accessing Google services. For example, Google Drive integration and auto completion. All that is Chromium specific is under this layer and CEF provides this runtime by patching the Chrome layer heavily to make it a public API. That's not the case for the regular implementation. So I just wanted to show how we use CEF on current one implementation. All those classes are based on the CEF representations of the browser and the renderer processes. Basically, we run a browser process and then each time we run another application it's going to create new processes for managing that specific application. And we leverage from the window and browser view delegates from CEF to create the web app and web pages representations used on one. So for this year our goal was to make make it possible to switch to CEF. We created the CEF recipe earlier in June and we added a CEF feature that we could use to tell the build system that we are going to use the CEF backend for one. But it was still possible to use Chromium WebOS as well if you didn't use this feature. Now we are in the phase of hardening, doing some hardening and bug fixing. One of the things that we improved was to start using official Chromium release torbles. The older recipe was based on the Chromium repository and it took a long time to clone and get other dependencies and the release torbles already contained all the code needed to build Chromium. So this decreased the download and build time a lot. And now we made CEF to the default backend for one. Now we'll keep working on bug fixing and also we need to bring the optimizations that are available on Chromium WebOS to CEF and to improve the development workflow for web applications to provide forms of inspection in real time and decide a new form of bundling that was available prior to the application framework deprecation. And now the only way of including a new web application is to create a new recipe added to the tree and bake a new image. So this was better before when we could basically just send a new bundled application to a running instance, install it and run and we need to bring this back possibly by working with PWAs. We are working on a whole UI revamp because we did a lot of work on the base of the system but we didn't work a lot on the UI and the work on creating the new recipe took a long time but it's not perceivable if you run the image it. It's the same as the old implementation and working for some time with the new site I started to notice a few pros and cons on using this new implementation. So like I mentioned we have faster fetch and build steps. It's easier to maintain because one thing that was a problem for us using Chromium WebOS was the time that it took to get a new milestone release from the project. Sometimes Chromium was jumping two milestones and the delta between between those versions was big and we needed to use a lot of time for adapting our changes to work with the new version and now since the releases happened very often we are always parting our patches and the delta is smaller and it takes less time to do the maintenance. One thing that's good and also brings some problems is to use newer versions of Chromium because of the CF updates. It's good because we can get new features faster and we also are getting all the security fixes that are released every two weeks but also we get a few problems because sometimes we get bugs that only happen on our platform or similar platforms but not on the usual Chromium targets and it adds some work to the maintenance to have to fix them. What's definitely an issue is the compiler issues that we get because of the difference in versions of Clunk used by Chromium and the Clunk used by the project and we get most of the issues from the C++ 20 features that are used and not supported on older compilers so we need to fix each case separately and it also adds to some time and if we could update the compiler version on the platform more often this would be less of an issue and yep basically that's it and I don't know if we have any questions about this so he's interested in CF and he wants some way of notifying you want to notify notification between applications or well actually I think it's not directly related what you've been presented it's more like about CEF because our colleague told us that they are stopping to use an open API for the web application notification like currently it is using it is used to pop up the notification but it's rumored they are not going to use it ever again kind of that kind of system it's like API or if you know anything and if you could share we'll be appreciate it yeah sorry I'm not aware about that I was thinking you were talking about notifications between different applications like some form of IPC or something like that yeah yeah okay so CF provides its own API for IPC we are actually using this as well and it's a very simple API it's based on JSON so you you create all the fields and send information you want I think I don't have the code of CF here to show you but you can check on the main page on Bitbucket and they have samples for IPC and users of JavaScript and some other cases yeah they are not planning to change the system of that you know that we're not not aware about this this change but yeah okay okay I think that's it then so thank you