[resent from an address mailman knows about] On Wed, Sep 24, 2008 at 3:36 PM, Darin Fisher <[EMAIL PROTECTED]> 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=20890that >> 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.) > > > >> 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. > > 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. > > > >> 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
