On Sep 24, 2008, at 12:14 PM, Amanda Walker wrote:
Hello all,
A conversation started on https://bugs.webkit.org/show_bug.cgi?id=20890
that Alexey suggested moving to webkit-dev, so here we go :-).
One of the things we ran into when bringing up the Chromium
application architecture was that we needed to distinguish between
"platform" and "application features". We took our cue from Apple's
combination of using PLATFORM(WIN) + PLATFORM(CG) for their windows
port, and created PLATFORM(SKIA) for the graphics library we're
using, and have started using PLATFORM(CHROMIUM) to denote "hosted
in a rendering subprocess, not a conventional view hierarchy"
independently of the OS and graphics API.
So for example, we'd like to continue to use PLATFORM(CG) to denote
"we're using CoreGraphics", PLATFORM(MAC) to denote "we're building
for Mac OS X", but add build-time control over things (primarily in
WebCore) that make application assumptions like "crawl up the view
hierarchy, test to see if our grandparent view is a particular
class, and send it a message". We've been intending to use
PLATFORM(CHROMIUM) for a bunch of this, but since the same issues
are likely to come up for other ports (embedded ports, a variation
on an existing platform that wants to render directly to a bitmap or
texture, etc.), it would be great to get input from others,
especially people working on other platforms & ports.
We'll probably continue with our current approach for the moment,
since it does have precedent, but we won't be the last to run into
this issue, so if there's a better way, We'd love to start figuring
out what it would be.
Here's a few of my thoughts, as the person who introduced the
PLATFORM() macro system as we know it:
1) PLATFORM macros should primarily be about use of particular
underlying libraries technologies that a port sits on top of. 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.
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.
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. 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.
3) PLATFORM(MAC) is not in any way the equivalent of PLATFORM(WIN_OS),
that would be PLATFORM(DARWIN). The latter two, like PLATFORM(LINUX),
represent low-level OS dependencies, below the GUI layer, and would be
used even by ports which were based on a cross-platform GUI toolkit.
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. PLATFORM(GTK), PLATFORM(QT)
and PLATFORM(WX) all follow this concept fairly well. However,
PLATFORM(WIN) and PLATFORM(MAC) are a little confused in various ways.
Currently Apple's windows port is defined by the combination of
PLATFORM(WIN) and PLATFORM(CG).
There should probably be an overall PLATFORM(WIN_APPLE) or the like
which defines the port that runs on Windows and uses Apple's various
ported libraries. Or perhaps WIN_CG or WIN_CGCF to make it more about
technology and less about company name.
Similarly, PLATFORM(MAC) mixes together use of Cocoa, use of other
underlying Objective-C or even C libraries that are only on the Mac,
and being a primary port define. I think this define should be
primarily about use of Cocoa and if there are ports that wish to use
Cocoa but not other underlying technologies then we should consider
splitting them out into their own USE or PLATFORM macros.
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?
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
