<div dir="ltr">[resent from an address mailman knows about]<div><br></div><div><br><div class="gmail_quote">On Wed, Sep 24, 2008 at 3:36 PM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@google.com">darin@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div dir="ltr"><div class="gmail_quote"><div class="Ih2E3d">On Wed, Sep 24, 2008 at 2:16 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote:<br>
</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div></div><div><br><div><div>On Sep 24, 2008, at 12:14 PM, Amanda Walker wrote:</div><br><blockquote type="cite"><div dir="ltr">Hello all,<div><br></div><div>A conversation started on <a href="https://bugs.webkit.org/show_bug.cgi?id=20890" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=20890</a> that Alexey suggested moving to webkit-dev, so here we go :-).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
</div></blockquote><br></div></div></div><div>Here's a few of my thoughts, as the person who introduced the PLATFORM() macro system as we know it:</div><div><br></div><div>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.</div>
</div></blockquote><div><br></div></div><div>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.)</div>
<div class="Ih2E3d">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div> 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.</div>
</div></blockquote><div><br></div></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div class="Ih2E3d">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><br></div><div>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.</div>
<div></div></div></blockquote><div><br></div></div><div>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).</div><div class="Ih2E3d">
<div><br></div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>I would like to understand the broader context a bit. Does the Chromium Mac port intend to use a different network back end?</div></div></blockquote><div><br></div></div><div>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!? ;-)</div>
<div><br></div><div>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.</div>
<div class="Ih2E3d">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div> 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.</div>
<div><br></div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div><div>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). </div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div></div><div><br></div><div>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?</div>
<div></div></div></blockquote><div><br></div><div><br></div></div><div>I can go into further details, but maybe what I've written so far will spawn some more questions?</div><div><br></div><div>-Darin</div><div><br></div>
<div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><br></div><div>Regards,</div><div>Maciej</div><font color="#888888"><div>
<br></div><div><br></div></font></div><div class="Ih2E3d"><br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div></div>