[webkit-dev] PLATFORM(CHROMIUM), etc.

[Darin Fisher]

As some of you may have noticed, there is now a PLATFORM(CHROMIUM) define
that is being used in WebKit.  I thought it might be helpful to describe
what it is and explain why it exists.

PLATFORM(CHROMIUM) corresponds to the WebKit porting layer implementation
used by the Chromium (aka Google Chrome) browser.  While Chromium runs on
Windows (and soon Mac and Linux), it turns out that it puts an interesting
set of constraints on WebKit that cause the existing WebKit ports to be
mostly unusable by Chromium.  The main constraint is the Chromium sandbox,
in which WebKit is run.  This technology does things like block access to
the filesystem, registry, sockets, and desktop (aka GUI system).

This latter constraint is the most impactful one since it means that HWNDs
associated with the desktop cannot be accessed or modified by the sandbox.
 This ends up having huge implications for not only rendering but also popup
menus, context menus, drag-n-drop, clipboard operations, theming, cursors,
and event processing.  All of those things need to be handled in the main
process that does have access to the desktop.

So, while we started out with PLATFORM(WIN) as the basis of our port, we
ended up touching and heavily modifying just about every file in the
WebCore/platform/win/ directory.  In the process, we also built-up
essentially a toolkit within the Chromium source tree on which our port was
then based.

In hindsight, it is obvious to me that what we were building was really just
a new WebKit port, and so we moved all of our work to the PLATFORM(CHROMIUM)
define.  We are in the process of upstreaming that port, starting with a
sprinkling of PLATFORM(CHROMIUM) defines in WebCore that eliminates
modifications to shared files.  In the coming months, we plan to upstream
the rest of our port.  We haven't been able to do so yet because we are
trying to move ourselves to tip-of-tree WebKit first.

In the long run, I suspect that there will be some commonalities between
PLATFORM(CHROMIUM) and the other ports that we can work to eliminate.  I
look forward to getting to that point.  For now, the plan is to upstream
PLATFORM(CHROMIUM) as a complete entity.

Other defines:

The Chromium build of WebKit also includes some other changes to WebKit
beyond just a new porting layer.  I thought I should talk about those too.

USE(V8)
  This corresponds obviously to the V8
<http://code.google.com/p/v8/>JavaScript engine used by Chromium.  In
our tree, we have a liberal
sprinkling of these defines.  Instead of upstreaming those wholesale, we are
working to build thin abstractions in WebCore that hide the underlying JSC
and V8 data types and method calls.  In some cases, this ends up simplifying
some existing JSC-using code, and I hope that this will be well received.

USE(SKIA)
  Chromium uses the Skia graphics
engine<http://blog.chromium.org/2008/10/graphics-in-google-chrome.html>to
perform 2D rendering on Windows and Linux.  (On Mac, Chromium is using
CG.)  Our intent is to upstream a platform/graphics layer built on top of
Skia that will be generally useful to ports.  For those who are unaware of
Skia, it is the graphics engine developed for the Android mobile OS.

USE(GOOGLEURL)
  As has been discussed at length in another thread, Chromium also uses the
GoogleURL <http://code.google.com/p/google-url/> library for URL parsing and
canonicalization.  We implemented the KURL interface on top of GoogleURL so
that we could have consistent URL parsing and canonicalization throughout
the entire product.  This was done to ensure correctness, which helps
avoid/eliminate classical security bugs, and help achieve good performance
when converting between KURL and GURL.

To be clear:  Our intent is to minimize the occurrence of any of these new
#ifdefs in the shared, cross-platform WebKit code, so that we minimize any
maintenance burden related to these new defines.

I'm very excited to finally have the chance to share our work with the
WebKit community.  I really look forward to having Chromium live at
tip-of-tree WebKit, so that we can work alongside you on more interesting
improvements and innovations to the core rendering engine.

Regards,
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20081028/6a95e744/attachment.html>