[webkit-dev] Announcing WebKit2

Darin Fisher darin at chromium.org
Fri Apr 9 14:36:18 PDT 2010

On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich <cwzwarich at webkit.org>wrote:

> On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote:
> On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat <treat at kde.org> wrote:
>> On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote:
>> > On Apr 8, 2010, at 6:23 PM, Adam Treat wrote:
>> > > Can someone please point to the bug report and the forum where this
>> > > development was discussed by the greater WebKit community?
>> >
>> > The time for that discussion is now. The forum is here.
>> >
>> > I suggest we use this mailing list, not a bug report.
>> Isn't that a little cart before the horse?  It is already actively being
>> landed...
> I'd have to agree.  A new port is a maintenance burden on the entire
> community.  Normally we discuss such things before starting to commit them.
> We seem to welcome pretty much any port that has an active maintainer.
> In the past we have accepted the Chromium port despite it having a new JS
> engine, new DOM bindings, an overreaching catch-all #ifdef for unrelated
> changes, numerous layering violations, and seemingly unnecessary changes or
> replacements of platform-independent code. All of these problems were
> discussed on webkit-dev and in Bugzilla prior to Chromium landing, but they
> were largely ignored and still exist today.
Perhaps we should discuss some of these problems that you perceive to still
exist with the Chromium port at the WebKit conference.  I'd like to
understand better.

I have heard/read some arguments in favor of breaking PLATFORM(CHROMIUM) up
into separate defines, and that all sounds conceptually reasonable, but
there hasn't been much of a need to do so since there have been no other
ports interested in sharing portions of what is currently behind
PLATFORM(CHROMIUM).  Perhaps we're at a point now, because of WebKit2, in
which we would benefit from sharing code that is presently behind


> For example, my first question is whether we can adapt the Chromium WebKit
> API (or devise an API that could replace the Chromium WebKit API) since it
> sounds like our goals and the goals of this new API are fairly similar.  If
> we do the former, I'm sure we can talk about changing the name.  :-)
> As it stands, there is no way for a WebKit port to opt in to Chromium's
> multiprocess model, and making this possible has never been a priority for
> the Chromium team. WebKit 2 looks a lot cleaner in this respect.
> Cameron
> _______________________________________________
> 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/20100409/9b4ffcd7/attachment.html>

More information about the webkit-dev mailing list