[webkit-dev] Some thoughts about platform flags

[Amanda Walker]

On Wed, Sep 24, 2008 at 5:16 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> 1) PLATFORM macros should primarily be about use of particular underlying
> libraries technologies that a port sits on top of.

This is where things get a little messy (at least in their current
usage), but it makes good sense to me.

> When it is necessary to
> compile differently for the sake of particular features, I think it would be
> more appropriate to use an ENABLE or USE macro. Given this,
> PLATFORM(CHROMIUM) does not make sense to me, as it names a browser using
> WebKit, not a set of underlying libraries. It also would likely mean pretty
> different things on Mac and Windows, if you intent to use CG instead of Skia
> on Mac for instance. If this define is meant to represent "hosted in a
> rendering subprocess", then it should be called ENABLE(MULTIPROCESS) or
> something along those lines.

Ah, I like that.  That's closer to what we're aiming for in most cases.

> Right now the only use I see of PLATFORM(CHROMIUM) in WebCore is to define
> USE(V8), which is then not ever used. Using V8 seems unrelated to the
> "hosted in a rendering subprocess" concept you described.

That's correct.  Any port should be able to pick up and use V8,
independently of any other aspect.

> 2) USE(NSURLRESPONSE) does not fit the concept of platform macros either.
> It's not about using an underlying library like CURL or pthreads or Qt's
> unicode support. And NSURLRESPONSE is a poor name for the feature; if it's
> about the network library overall, that's not a very good name, and if it is
> about this one use, the class involved isn't even NSURLResponse.
> I would like to understand the broader context a bit. Does the Chromium Mac
> port intend to use a different network back end? If so, then probably all
> networking code currently under PLATFORM(MAC) should be placed under
> USE(NSURLCONNECTION) to parallel USE(CFNETWORK) or USE(CURL). However, that
> should be done for all the NSURLConnection networking code, not just this
> one place.

Yes, this is exactly the issue in this case.  We may end up using
NSURL (and expect to use at least parts of CFNetwork), but we aren't
doing so in the same process that WebCore is in--so we have our own
set of resource loaders, etc., which will be pulling data into WebCore
over an IPC connection rather than directly.

The renderer process will be using CoreText, CG, some Cocoa, etc., but
using the Apple WebView sitting inside an NSScrollView which is in
turn inside an NSWindow--we must introduce a proxy, since remoting
NSView or NSWindow over DO doesn't work terribly well.  This is part
of what gave us the idea of using a flag that denotes the
architecture, since the code changes are there to support this
difference in architecture, not platform per se.  However, I agree
that USE or ENABLE on specific architecture features is a much better
way to do this.

> Maybe there is some other reason you wish to disable this client
> callback, if so, please clarify. I think the concept of a build that uses
> the Mac GUI-level code but some other network library instead of
> NSURLConnection makes sense and in other cases, network libraries use a
> separate feature define from the GUI-level PLATFORM macro.

Yes, that makes perfect sense.

> 4) What has sort of evolved with the platform macros is that there is a
> "primary" one that generally drives settings of subsidiary macros. The
> "primary" platform is either a GUI toolkit or a platform with a specific
> strong assumption of GUI toolkit.

Understood--and that's what we are tripping over :-).

> Anyway, I don't think we want to end up with a bunch of #if PLATFORM(MAC) &&
> !PLATFORM(CHROMIUM), so let's pause for a second to think about what
> Chromium's version of the Mac port would want to do differnetly, what the
> reason for those differences is, and based on that what new
> PLATFORM/USE/ENABLE macros should be introduced. Can any of the Chromium
> folks give an overview?

I can give a basic overview, with the understanding that the Mac
version of Chromium is a work in progress.  Here are the major things
we currently have on our radar as being very different from how
Apple's port currently does things:

- A WebView that is not an NSView, but rather provides a
CGBitmapContext in shared memory, and propagates events and paint
updates across a Mach port
- Resource loading (files, network data, etc.) in a different process
than page rendering
- plugins running in their own process, similar to the way that the
renderer process is running in a subprocess of the main browser
application.

For rationale, I can go into detail if anything's not self-evident.

Each of these things would certainly make sense as USE/ENABLE flags
that are independent of the platform--I could see a 64-bit Safari
wanting to run 32-bit plugins in a subprocess, for example.

--Amanda