[webkit-dev] Some thoughts about platform flags

Wed Sep 24 16:25:30 PDT 2008

On Sep 24, 2008, at 3:36 PM, Darin Fisher wrote:

> On Wed, Sep 24, 2008 at 2:16 PM, Maciej Stachowiak <mjs at apple.com>  
> 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
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080924/0a15df6c/attachment.html 