On Fri, Apr 9, 2010 at 2:36 PM, Darin Fisher <da...@chromium.org> wrote:
> 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, 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? -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
