On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich <cwzwar...@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 <tr...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev