On Wed, Sep 24, 2008 at 5:16 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
