El lun, 21-01-2013 a las 17:57 -0800, Sam Weinig escribió: > Hi Mario, > > The motivation of the change was to reduce the chatter between the > WebProcess and UIProcess and reduce the amount of knowledge the > UIProcess has about the internals of the WebProcess. We will also be > removing the UIProcess' notion of the frame tree, for the same reason.
Now that you guys can break other ports at any time, would it be possible that those changes are announced in advance here so that we have some time to prepare for the change? I don't mean all changes that might break the build and are easy to fix, but changes like that one that break the C API, remove functionality, etc. that require a lot of work adapting to them. > Going forward, if you need that kind of detailed knowledge, you should > use the WebInspector or the protocol it is based on. The GTK+ API depends on the WebResource API, so WebInspector is not a solution, 14 unit test are timing out now that resources don't work at all. We'll rework it using injected bundle, but I'm afraid the injected bundle API could be removed too, are there any plans in that regard or can we safely use the injected bundle API? > -Sam > > On Jan 21, 2013, at 5:53 AM, Mario Sanchez Prada <[email protected]> > wrote: > > > Hi, > > > > So it seems WebKit2GTK+ builds are broken since yesterday due to this > > commit (as it was already predicted by EWS in [1]): > > http://trac.webkit.org/changeset/140285 > > > > ... and it seems to me it’s not something easily fixable since it will > > certainly require a certain amount of work (and maybe a certain amount of > > re-design too) to get it back, as the WebKitWebResource API (as well as > > certain parts in WebKitWebView API) did benefit of both > > WKResourceLoadClient and WebResourceLoadClient. > > > > I’ve checked the related bug [1], but still haven’t been able to properly > > understand what’s exactly the reason of this change and, more importantly, > > what could be the best way to sort this out in the GTK port (an alternative > > implementation using the Injected Bundle perhaps?). > > > > If anyone could drop some light on this issue or provide some pointers to > > better understand the motivation of this change, I’d really appreciate > > that. I understand rolling r140285 might be not the best option at this > > point, yet I’d personally rather not keep the WebKit2GTK+ broken for too > > long. > > > > Thanks, > > Mario > > > > [1] https://bugs.webkit.org/show_bug.cgi?id=107405 > > _______________________________________________ > > webkit-dev mailing list > > [email protected] > > http://lists.webkit.org/mailman/listinfo/webkit-dev > > Hi Mario, > > > The motivation of the change was to reduce the chatter between the > WebProcess and UIProcess and reduce the amount of knowledge the > UIProcess has about the internals of the WebProcess. We will also be > removing the UIProcess' notion of the frame tree, for the same reason. > > > Going forward, if you need that kind of detailed knowledge, you should > use the WebInspector or the protocol it is based on. > > > -Sam > > On Jan 21, 2013, at 5:53 AM, Mario Sanchez Prada > <[email protected]> wrote: > > > Hi, > > > > So it seems WebKit2GTK+ builds are broken since yesterday due to > > this commit (as it was already predicted by EWS in [1]): > > http://trac.webkit.org/changeset/140285 > > > > ... and it seems to me it’s not something easily fixable since it > > will certainly require a certain amount of work (and maybe a certain > > amount of re-design too) to get it back, as the WebKitWebResource > > API (as well as certain parts in WebKitWebView API) did benefit of > > both WKResourceLoadClient and WebResourceLoadClient. > > > > I’ve checked the related bug [1], but still haven’t been able to > > properly understand what’s exactly the reason of this change and, > > more importantly, what could be the best way to sort this out in the > > GTK port (an alternative implementation using the Injected Bundle > > perhaps?). > > > > If anyone could drop some light on this issue or provide some > > pointers to better understand the motivation of this change, I’d > > really appreciate that. I understand rolling r140285 might be not > > the best option at this point, yet I’d personally rather not keep > > the WebKit2GTK+ broken for too long. > > > > Thanks, > > Mario > > > > [1] https://bugs.webkit.org/show_bug.cgi?id=107405 > > _______________________________________________ > > webkit-dev mailing list > > [email protected] > > http://lists.webkit.org/mailman/listinfo/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo/webkit-dev Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
