[webkit-dev] WebCore/platform directory

[Sebastien Roret]

I'd like to share with you some ideas we had about the platform/ directory.
First, our aim is to use WebKit on embedded platforms. We did a sample Linux
implementation based on SDL.
It was easy to see what we needed to implement thanks to the platform/ dir.
But hopefully we will have to do many ports, and some parts have to be
reusable as is.

On way to ease those ports was to abstract all headers in platform/ (only
pure virtual methods in classes). Thus, headers in platform would be truly
platform-independent. Moreover we avoid the need of adding a #ifdef for each
platform. The platform/ dir can then be considered as a Browser Abstraction
Layer.

We started from Mike Emmel's GDK port, we cut out platform into several
subdirs placed in BAL/Implementation :

   - Events, abstracted events and event loop ;
   - Fonts ;
   - Graphics, abstracted GraphicsContext, and files as in
   platform/graphics/ ;
   - ImageDecoders ;
   - Network ;
   - Types, various cross-platform types ;
   - Widgets.

And in BAL/Interfaces, all abstract headers that should be implemented in
BAL/Implementation.
We also thought of an abstraction for :

   - Internationalization (ICU library);
   - Posix (libm, memory manager for now);
   - XML (libxml and libxslt).

This way, the BAL is independent of WebCore and can be compiled aside. Unit
tests have been written and are reusable for each platform.

What do you think about this choice for platform/ ?
We plan to publish this sample implementation and the abstraction layers
impacting changes as soon as we've reached a reasonably stable and mature
level.

Sebastien.

On 12/5/06, Darin Adler <darin at apple.com> wrote:
>
> Recently, we discussed the platform directory a bit in a bug <http://
> bugs.webkit.org/show_bug.cgi?id=11596>.
>
> I thought I'd say a few things on this point to the entire list.
>
> The "platform" directory is where we have the platform that the rest
> of WebCore is built on top of. The primary focus is platform-
> independent wrappers for platform specific services, like events,
> graphics systems, as well as some basic data structures.
>
> The platform independent interfaces and implementation are at the top
> level, and platform-specific implementations go into directories
> named with the nickname for each platform (e.g. "mac" for Macintosh,
> "qt" for Qt, "win" for Windows). Since most headers are shared, some
> platform-specific code is in the headers guarded by appropriate #if
> statements.
>
> We also expect to have platform-specific implementations in some
> other places in the source tree. What goes into the platform
> directory is a platform abstraction that the rest of the library is
> built on. But in some cases, you can't build the platform specifics
> into a platform abstraction -- you need platform specifics in the
> higher level code.
>
> At the moment, a couple of directories that are have this kind of
> platform-specific code are page and loader. (Much of the code
> currently in bridge/mac belongs in page/mac.) While we'd like to keep
> from doing this all over the code, we will need platform specifics
> outside the platform directory when they can't easily be abstracted
> into a generic cross-platform concept.
>
> I see signs that people are misunderstanding this approach a bit. For
> example, FrameQt and PageQt absolutely do not belong in platform/qt.
> They should be in page/qt instead.
>
> I'm sorry that this wasn't explained clearly enough in the past.
>
>      -- Darin
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20061206/f3d9863e/attachment.html