Wilson: Hi. I'm Brett, if you don't know me.
Okay, so I'm gonna be talking about...
Not working. Okay.
Okay. I'm gonna be talking about the layers of our program.
Chrome is like an onion or a parfait,
where there's many layers that go deeper and deeper.
[laughs]
Onion parfait.
So first I'm gonna show you
how to get to the information that I'm gonna tell you
so you can look it up later when you aren't watching the talk.
So this is the Chromium developer site
on dev.chromium.org.
And what you do is you first click on For Developers,
'cause you're a developer.
And...the things I'm gonna be discussing
are under the engineering design docs here at the bottom.
So if you go to the engineering design docs...
these first two things are probably the most important.
So there's the Multi-process Architecture
which Darin talked about,
and here it's got an overview of everything.
If you're confused about what Darin said,
this is a good place to start.
Um...the other thing to look at is...
how Chromium displays web pages,
which is what I'm gonna be talking about today.
So it's got a discussion of everything.
You have diagrams and stuff like that.
So this is one of the diagrams from that page
that I'm gonna be discussing a lot.
So Dimitri just talked about WebKit,
which is at the bottom.
That's kind of our low level library that we use
for rendering web pages.
As he said, that lives on webkit.org,
and if we change it, you have to change it on WebKit,
and then we pull it to our tree.
So historically we also had a WebKit port,
and the WebKit port provides integration
with the graphics layer like Skia, system fonts,
the network.
And we've got our own implementation
of all those things-- that's called our port.
And we've recently moved our WebKit port
into the WebKit tree.
So that means anytime you need to change something
with fonts or graphics,
you're gonna have to also make it a patch to WebKit,
even though it only really affects us right now.
So these two things, both of them on WebKit,
and they cannot depend on any other parts of Chrome.
Because they live in WebKit's tree,
they should be able to compile by themselves.
[clears throat]
So the next layer is the WebKit glue
which we have in our WebKit directory/glue.
And that kinda provides a wrapper around WebKit
that we use to access it.
And so it does several things.
It provides, uh... type independence.
So WebKit uses its own string types,
its own URL types.
It has lots of dependencies all over the place.
And we don't wanna have Chrome inherit all that stuff,
'cause we're gonna be confused with, you know,
ten different string types and, uh, you know,
two URL classes.
So the WebKit glue's job is to translate types
between, for example, a GURL and a KURL...
Um...or a WebCore string to a standard string.
And so it kind of provides all the, uh...
an implementation of all the interfaces
that WebKit uses.
So there might be a frame loader client callback thing.
It will implement its own,
convert it to Google types,
and then it will have its own callback interface
that you'll have to implement.
So there's kind of a hop as you go across this boundary.
And so if you do need to get something...
if you're in our WebKit port
and you need to get something from the browser,
like the browser process or something higher level,
you actually have to go through this delegate interface.
That hops through to the WebKit glue,
and then that's implemented at a higher level.
So the WebKit glue
shouldn't depend on any other parts of Chrome.
It's basically our embedding layer,
so you should be able to write a new browser
using our WebKit glue, totally different in every way.
And we have such a browser called TestShell
which is a separate browser that just uses our WebKit glue,
has its own simple front end, and that's it.
So TestShell can't depend on any other parts of Chrome
other than base.
So, um, here's our directory.
So base here at the top is kind of used by everything
except the WebCore code, which obviously isn't ours.
So WebKit glue depends on this.
We've got our network library that depends on this.
You know, we've got our sandbox that depends on this.
But basically nothing else here except Chrome
depends on anything but base.
So for example, Net doesn't depend on
you know, Media or ICP or Gears or Chrome.
And then Chrome kind of brings all these things together
into the final product.
So hopefully, this makes it easy for projects
to pick up our different components
from these top level directories.
They just have to take base and the sandbox or whatever.
So um...
Okay, so WebKit glue depends on base, and that's it.
So you can write a new browser, um...
that's single process.
Or you can use our multi-process embedding layer,
which is, as Darin talked about,
it's got the RenderProcess and, uh--
okay, let me talk about that. [laughs]
So the RenderProcess
is kind of implemented in this render project
which is in Chrome/renderer.
So these are things like RenderView and RenderWidget.
They're called Render. Everything starts with Render.
And that talks to the corresponding interfaces
on the browser side.
So each interface in Render has a host
in the RenderHostDirectory
called RenderViewHost or RenderWidgetHost.
So these two things kinda go together.
They're both sides of the pipe.
And if you wanna write a multi-process browser,
you use this Renderer host layer,
which is in chrome browser/render_host.
And just like with glue,
it shouldn't depend on other parts of Chrome.
So it shouldn't know anything about our browser
or the fact that we have tabs or anything like that.
And if you wanna write a multi-process browser,
you should be able to grab this layer
and you're, you know, ready to go,
writing everything else different.
Um...so we aren't perfect in this respect.
Sometimes it has some bad dependencies.
But please don't add more.
So one way to think about this is, you know,
say you're writing a dialogue box
that has a web page in it,
but it looks kinda like a dialogue box.
You should be able to embed this Render host,
like a RenderViewHost, in that
and just kind of get a web page.
It shouldn't have all these things like a password manager
or history or anything like that.
So if you're wondering where to put stuff,
if you need it in a dialogue box
or something very simple like that, put it there.
If it depends on other parts of Chrome,
put it in a higher level.
So the Renderer host has a delegate interface
which is how it talks with the higher levels.
So that's implemented of our tab contents layer.
And that's kind of the layer that really integrates
with the rest of the browser services.
So for example, it talks to history,
it talks to, you know, the password manager,
the navigation list for back/forward
and all that stuff.
So tab contents kinda brings everything together.
And, uh, above the tab contents is the browser window.
So you shouldn't ever be talking up directly,
so tab contents has a tab contents delegate
that browser window implements.
And in fact, other parts of our system
actually use tab contentses that aren't their browser window.
So you shouldn't ever depend on, you know,
being in a browser window.
So you talk up through your delegate
to talk to the browser window.
The browser window has the tab strip,
manages tab switching, stuff like that.
So obviously, it's easy to talk down.
The browser window can talk to any of its tabs.
The tab contents can talk to the Renderer host.
These talk to glue, and glue talks to WebKit.
And one of the things we have on the buildbot is...
this check deps... which is not here.
It was on the old build.
How do we get to the old build? Does anybody know?
Oh, the old buildbot?
Okay, anyway, so there's one step with the build.
This has check deps.
Man: Waterfall...[indistinct]
Wilson: Um...so this check deps
tries to enforce that you don't include
files from other parts of the project
that you're not supposed to.
So...let's see.
Okay, so here, one of the first steps on the main buildbot,
it updates and then it runs through this check deps program.
So if you ever see check deps go red,
that means that your change, you know, for example,
included something that it wasn't supposed to
like made a dependency from the network library
to Chrome.
So if this ever goes red, you need to back out your change
or fix it really fast.
Uh...not...not just make it so that
inclusion doesn't break the build.
'Cause that is telling you that you're not supposed to do that.
To try to kinda keep us honest.
And it's got a--
if you have any questions, you can ask me about that.
It's got files in each directory that kinda show...
oh, files in this directory are allowed to
include base and net but nothing else.
So there's kind of a set of hierarchical rules
that it uses.
And... that's my whole talk.
Anybody have any questions?
Peter: How does Darin's rewritten Chromium port
affect all this stuff?
Wilson: I'm--I don't know.
Uh, Peter's asking
how Darin's rewritten Chromium port in WebKit affects this.
I think it will go kind of in-between glue and WebKit.
It's kind of--it will be using WebKit type,
so we'll still need a glue layer to convert types.
But it would be a more stable API,
because right now WebKit glue
kinda talks to these crazy WebKit classes
that change every day and causes such problems.
But I haven't seen it. [laughs]
Peter: Is it feasible someday to pull out
like the Renderer host into source/rendererhost
or something above Chrome if it's supposed to be
kind of like a usable embedding layer?
Wilson: Peter asked if he could pull Renderer host
out of the Chrome browser directory.
Maybe we haven't had a need for that.
But it would be nice if we were able to
and it had like no dependencies.
But it does.
Um...yeah.
I can't think of any reason why it shouldn't be possible.
Peter: Then you have-- you could rename WebKit glue
to be like, you know,
single process embedding layer as a thing,
and then this would be multi-process if anything.
Wilson: Okay, Peter has some crazy naming ideas.
[laughter] Peter: Thank you.
Wilson: [laughing]
Any other questions?
Okay.
[applause]