[webkit-dev] Announcing WebKit2
darin at chromium.org
Fri Apr 9 14:39:00 PDT 2010
On Fri, Apr 9, 2010 at 2:36 PM, Darin Fisher <darin at chromium.org> wrote:
> 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
>> 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, Sam mentioned that WebKit2 might want to use the
BackForwardListClient that we added for the Chromium port. It seems like a
trivial change to invent an ENABLE option for that so that it can be shared.
Are there more examples?
>> 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.
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev