[webkit-dev] Announcing WebKit2

[Darin Fisher]

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
PLATFORM(CHROMIUM)?

Regards,
-Darin



> 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>