On Sep 24, 2008, at 3:36 PM, Darin Fisher wrote:
On Wed, Sep 24, 2008 at 2:16 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
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.
Actually, we do have a set of underlying "libraries" corresponding
to the base/ and net/ directories in the chromium source. Our
webkit port leverages elements of those modules. We have to decide
if a PLATFORM(CHROMIUM) implies a dependency on those modules or if
we should instead move our port to not depend on those modules by
introducing another abstraction layer. (I suspect that an
additional abstraction layer is a bad idea.)
I'm not really familiar with what is in these libraries. Could you
give a brief outline?
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.
I don't think anything about our port implies hosted in a rendering
subprocess. Our port works perfectly well in a single process
traditional browser model. We build two embedding apps based on our
port of WebKit: test_shell and chrome. The former is like a mash-
up of DRT and Spinneret.
OK; that appears to disagree with what Amanda said above.
Our port satisfies many of the requirements of a multiprocess
rendering engine, but it also satisfies many of the requirements of
a headless WebKit (a.k.a. rendering to memory, sans-widget system).
At the moment, much of our port leverages the PLATFORM(WIN), but in
many cases that was done to reduce the forking of WebCore. So, we
have some work to do to disentangle our overuse of PLATFORM(WIN).
Porting chromium to mac and linux is a forcing function for much of
that cleanup.
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.
We don't use PLATFORM(CHROMIUM) that much yet. I agree that USE(V8)
is or should be completely orthogonal to things like
PLATFORM(CHROMIUM).
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?
Chromium will use the same network stack on all platforms. From the
point-of-view of WebKit, we implemented a ResourceHandle that just
delegates to the embedder. Our glue layer (our WebKit layer)
provides an interface named ResourceLoaderBridge (how about that
name eh!? ;-)
So as you can see that "network stack" is very thin from the point-
of-view of WebCore. It is just a bridge. At the layer we do take
advantage of some types defined by our net/ module, however, so it
is not completely without ties to the chromium platform.
Then it sounds to me like there should be a separate USE or PLATFORM
macro for NSURLConnection, separate from Cocoa/CG UI, since you want
the latter but not the former. It might also make sense to have a
separate macro for your network library. That would probably be better
than using PLATFORM(CHROMIUM) as a catchall, since as we are now
learning, having a single macro cover multiple arguably orthogonal
platform choices can create trouble down the road.
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?
I can go into further details, but maybe what I've written so far
will spawn some more questions?
-Darin
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
