Okay, let's start off then.
So, first off, please.
Thank you.
Okay, now it's working.
Okay.
So, we're going to talk first about what is WAM.
WAM stands for Web Application Manager.
It's the LG WAM OS WAM runtime.
It's built on top of Chromium nowadays.
Web OS.
It's an operating system for embedded products.
It's authentic.
So, the idea is that web applications are first-class citizens
to the same level or native applications
or even more prominent in web OS.
The components is built on top of Jokto.
It uses Wayland for graphics with QML
for the Wayland compositing and Mali for biter keyboards.
It has a unified media server.
For IPC between applications, it has a JSON protocol
that is named Luna.
So, yeah, WAM is the centerpiece of the web experience
in web OS.
So, places where it was used, HP Touchpath a long time ago,
there were some palm phones where web OS was part of the palm offering.
Nowadays, it's the key part of the web OS, the LG Smart TVs.
From 2013, that's the main OS to use for those TVs.
So, we have hundreds of millions of users using this.
Other products we have implemented in the web OS
and ROS integration.
So, we have some robot experiments, digital signage,
some appliances like this fridge, and wearables like this clock.
It is used from 2018 in the web OS open source edition.
So, basically, it's a public distribution with open source
basing all these components.
It is used nowadays also on AGL, on the Automated Linux.
It's the web runtime for AGL.
So, there was a part of the LG web OS web runtime to the AGL
that is not web OS.
How it works?
So, this is the architecture.
The reddish areas are what is implemented by Chrome.
Orange part is the, nowadays it's also part of Chrome,
but it's the integration with Wayland.
There's the blue parts that are provided by web OS,
that are the Wayland Compositor and the IPC.
And one is the green part.
So, it's built on top of Chromium that handles the running web
application of the system in an efficient way.
So, the thing, why we want to put one in OS?
Basically, the idea is having high support for the web platform
nowadays.
Web platform moves fast, so if you want to get up to date
to the latest standards, you need something that provides
the web standards and moves as the Chrome and baseline
moves get the latest web standards.
It controls the application lifecycle.
So, basically, when you run a web application,
one takes care of running it, of closing it,
of reducing the saving memory resources,
CPU resources, GPU resources,
so they are properly distributed on the system,
saving CPU and battery when applications are not
visible to the user.
So, yeah, that's one of the great advantages
is this single runtime gives some performance improvements
because we are sharing as much possible resources
for running web content.
Thus, the last one, launch time optimization,
it's also quite critical because running a web stack
is quite heavy thing nowadays.
So, being able to have things pre-launched, pre-warmed
is quite important for having a seamless web experience
where application launching is very fast
and application switching is also fast.
Our security, well, it has all the web standards
about how to run remote contents and also local contents
through security origins.
Security origins, basically, is the sum of a scheme,
the port, and the host part of the URL.
We have some permissions declared in our application manifest
so we can determine which parts of the system
a web application can use.
And about developer tools, we have basically the same
we would have on a Chrome browser.
So we have the Web Inspector on developer tools
and we have the Chromium Tracer for having
performance analysis in the system.
I think that one of the important things is that
it's been running for a long time in millions of LGTBs
on all the devices, so 10 years of experience,
it's proven, it's running, it's stable,
and it's used for a long time.
And now it's also out of the LGR reference platform, too.
So we have here some links for open source,
the open source flavor of WebOS,
and all the companies are the same as we have in Smart TVs,
Related to One, and WebOS OSC.
So basically, you use WebOS OSC,
you can try all these components in your own devices.
Okay, so let's move to the retrospective part.
As Said says, it's been 10 years.
The main caveat here is that I joined the WebOS project
in October 2012.
The history of one WebOS stand before 2008,
but I will mostly focus on what I lived
and not on what happened before.
Anyway, it's just lesson learned.
I hope some of them may be useful or insightful for you.
Okay, so a bit of history.
WebOS was developed by Palm that was acquired by HP
in 2010, and then on 2011 HP decides
that they don't want to develop any other WebOS product anymore.
So the last device is a tablet that is HP Doge Path.
But in 2012, there's a start of partnership between HP and LG
for pouring WebOS for the LG Smart TV box.
The idea was that WebOS could be the basis for the future Smart TV
offered by LG.
They had something that was named Netcast before,
and it was hard to maintain,
and it was hard to keep moving with what was required
for the future Smart TV OS,
because you would have more than one Web application running
at the same time that switched into that WebOS
were already providing at that time.
So 2013 basically what happened was that LG had acquired
the business unit that was found before.
So basically the business unit that owns WebOS.
That business unit was renamed to the LG Silicon Valley Labs.
At that time.
And from 2014, LG WebOS based TVs
introduced in computer entertainment show in Las Vegas,
and then the TVs were released a few months later.
I think it's April 2014, the first LG Smart TVs
based on WebOS.
Okay, more about open source.
As I said, HP Power decided to scrap all the WebOS new products,
so they stopped doing new products,
and they published most of the source codes
open WebOS with the idea, I think,
well, the feeling at the right time,
at that time that nowadays is the same,
they open it to attract interest in WebOS,
to attract investors.
Very likely they were already considering selling the business unit.
But when LG acquired the Power Business Unit,
they stopped maintaining open WebOS.
So they came back to the new open source developing model,
and that was kind of a strong problem.
But it was very, very hard,
the work to port WebOS for smart TVs
and releasing to products.
There is something that sometimes it's not very clear,
but when you have something like an open source product,
some upstream, some poly-produced,
but then you want to get to release quality
for a product for millions of users,
it's not easy.
There's a lot of work to stabilize,
to mature things, to even pass controls
by authorities of all quality.
It's not very easy.
So we all decided to focus on first having the smart TVs
running WebOS, and then open sourcing again
would be an afterthought after that.
Usually that doesn't happen in the end.
This kind of afterthought never happened,
but in this case it happened.
So in 2018, like six years after open WebOS was stopped, basically,
LG releases WebOS open source edition.
The focus was in this case allowing people to take this,
to prototype ADS, do experiments,
make things around WebOS,
because basically you would have a UI user experience
a way to integrate this in the web component.
Yeah, the idea is students, independent developers
would have a way to prototype and do things with that.
So again, the idea is creating a community around it.
So OSC is acting nowadays. After five years it's still there,
so it's not something that is going away.
The hardware technology nowadays is Raspberry Pi,
and nowadays it's Pi 4 model.
My view, it simplifies testing new ideas.
It allows to start things like integrating one WebOS part
in ROS for robotics and in EGL for automotive.
So yeah, it was quite a success in that regard,
but there are tons of experiments that have been happening
that are quite useful for understanding,
well, for prototyping product ideas.
So if you want to integrate WebUI
in your experimental product, OSC can help.
It's very easy to integrate web application, web contents,
both a party and even running locally.
Okay.
So how it happens, we have WebOS,
we have Open Source Edition.
There was the idea at the LSBL
that it would be interesting to port parts of Chromium,
the web runtime we have in WebOS to port it to EGL,
so it would have a web runtime with all the advantages
we talked about.
So it has been a collaboration between EGL and EGLia,
and then presented to the Linux Foundation,
so in the end, a collaboration among the three.
Before 2017, Galileo was assisting
porting Chrome browser adaptation to Wayland
on the Chrome browser, so it was running in EGL.
But in May, in 2017, my team in LG Silicon Valley Labs
did experiment to port one to EGL.
It was actually one month,
it was mostly working in two weeks,
and then we started maintaining it from 2019 to present.
Okay, the thing is that the experiment proved it was possible,
and now the focus is always moving to be able to run EGL
with only web UI, so basically the main UI
at that time in EGL was just in Qt,
and the idea was that if you didn't want to run on top of Qt,
you could run on top of one and half all the system UI
and don't ask for applications.
It also allowed to integrate with other applications,
add with the system services as provided by them,
and that's part of the continuous adaptation as EGL evolves
with different system protocols and system services
we need to evolve to catch up with that.
So that was what happened in the last four years.
We did one adaptation to EGL.
Okay, another evolution.
In 2012, we were using Qt WebKit.
We moved to Qt WebKit 2 in the first two years,
and the first web OS TVs were using Qt WebKit 2.
Then we moved to use Qt Web Engine.
The idea was that everybody was moving to blink,
and it was not as much more than that.
The idea is that we had this feeling that chromium blink
were moving faster while doing more
for the web platform.
So it would save costs for maintenance to move
to use an engine based on blink and chromium.
So yeah, we used Qt Web Engine.
Qt already has a part that would save us time
for doing that part.
But from 2015, we moved to create our own binding layer
and drop Qt Web Engine.
So this web OS WebView is a new component
that replaces Qt Web Engine.
One is built now on top of that.
Why?
The main reason, there are a few reasons,
but there was a concern about the licensing model
on Qt Web Engine at the time.
It was one of the first components that moved to LGPL v3.
So the way they contents about the patent clauses
and for a TV vendor, that was kind of a problem.
And not only a TV vendor, we found several others
that would have some concerns on that.
So there was no other Qt Web Engine use at the time.
So in the end, we did this.
We removed that dependency, at least in the Web Engine
integration side.
It was allowed to simplify the continuous upgrade
to track upstream Chromium at that time,
because at least the media stack in Web OS is way different.
So maintaining a different Web Stack on top of Qt Web Engine
on top of Chromium and trying to keep that baseline,
trying to keep upstream.
It started to become quite hard.
Then we did something different, and that's more recent.
One was based on Qt for a long time,
but there was concern from some stakeholders,
not LG, that has some partnership with Qt that is strong.
So it was not a problem, but for other stakeholders,
the CPL dependency was kind of a problem.
And the other reason for using Qt diminishes a bit,
because basically C++ and STL improved a lot
and simplified things.
So it was not that important to have all the pieces
that Qt was providing for free as part of the bundle.
So in last year, well, two years ago,
we moved to not depend on Qt anymore,
and now it's based on STL and other C++ libraries
for JSON passing and a bit of glib for the main loop.
We moved from Qmake to CMake.
Okay, but the thing is about stability.
One didn't change a lot in the last 10 years,
so the main ideas that we have running 10 years ago
are still there, the way we handle the way
running applications, et cetera.
So it has been useful.
The architecture has been flexible enough to adapt
to the web engine changes we explained,
new changes, new products, and even OS changes.
So we've been able to put one to different OSes,
different web engines, and it added very well.
So first, about the future,
why was STL here to stay?
LG is spending lots of money
on making it the main part for the OS TV offering.
They've been even allowing it to be used
for third-party TV vendors through the world-wide staff.
And there are some future discussions.
We are now using GCC for building.
We may move in the future to use Clang,
basically because it's the toolchain that comes about.
So maintaining both the chains is kind of problematic.
And we want to improve the upgrade cycles.
We want to be closer to up-synchromium.
So there are many reforms happening nowadays
to improve these also.
So these are the final remarks.
Yeah, 10 years of the project, more to come.
It's in millions of products.
It proved to be useful.
And it allows to create products offering,
I mean, don't put this in Arduino.
It's not going to work.
But for products with 512 MB, even 250 CSV,
it's possible to provide a good web experience.
So that's it.
And thanks.
These are the sponsors of the work.
So it's important to show them.
Thank you.
We have a few questions, starting with the online questions.
The question online was, if I have an LG TV
and they want to rebuild the firmware from sources,
is that possible?
I don't think you're going to know the answer to that one.
No.
The LG OS TV is proprietary OS.
I say that maybe around 10% of the software is proprietary,
but you cannot be the firmware.
And actually, TV industry is quite bad in that regard,
because of DRM and of the requirements of the TV
providers like Netflix, Disney Plus, all these kind of things.
They want to have a strong hold on how the contents are
delivered and when the contents are possible to be delivered
and paid and whatever.
So it's not all a thing about LG.
Samsung has the same problem.
Other vendors have the same problem.
It's that the industry that will deliver contents to the TV
are quite problematic in that regard.
That's something that I would like to see it improve.
Google has done a lot for at least reducing the pattern that
is related to the DRM, but that's a problem of the TV
industry that we need to deal nowadays.
So we manufacture OEM boards.
And over the years, we manufacture OEM boards.
And over the years, I find it really difficult to know
what kind of platforms.
I find it really difficult to recommend UX platforms to our
clients.
So nowadays, we're starting to look at Flutter.
That seems to be something people are talking about.
I'm really sort of not a UX person.
So when would you say we should be recommending this and WebOS
as opposed to other alternatives?
What are the sort of pros and cons, as it were?
Actually, there are different lines.
So for system UI, you can choose whatever you want.
Flutter is quite efficient.
Qt is quite good.
Web is possible.
The main thing is that, do you need web applications on top
of that?
Because you may want to play separate contents like Twitter
application that is web, like YouTube, silly that.
If you need separate contents, you may also want to have
a web runtime.
So you may have the need.
You may want to still use web also for the system UI.
It's your choice.
The tooling is a great advantage of web contents because
there are tons of developers.
There are tons of ways to do UI in web.
And it's pretty much a common standard for that.
But yeah, it's a choice.
Thanks, everybody.
Time's up.
Thank you.