<div class="gmail_quote">I'd also like to ask specifically for guidance from reviewers, especially on ports other than Chromium, about how to handle the new files in WebCore that are part of the Link Prerendering API. Should I add them to other ports build files?</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">The new files in WebCore that are only important to ports that have prerender on on are currently WebCore/loader/Prerenderer.*, WebCore/loader/PrerendererClient.*, WebCore/platform/PrerenderHandle.h. Those files basically all just have #if ENABLED(LINK_PRERENDER) surrounding the entire implementation. If you aren't using prerendering, they are empty files.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">I can see the arguments on this both ways. If I add them to the build files, then of course things will be easier for the lucky hacker adding prerender to another port in the future. We'll also benefit from having build files that are close to each other; every bit that we drift apart is more pain.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Against adding to the other ports, I see that these are translation units that will slow down compiles; this is particularly true for anyone building with a smaller number of CPUs, where compile time and not link time dominates. Why subject hard working hackers to any slowdown for a feature they don't use? And besides, prerendering is a complex feature with much deeper implications than WebKit; whoever turns on prerendering in other implementations is not going to be put off by adding a few files to their project.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">WebKit-dev, wdyt?</div><div class="gmail_quote"><br></div><div class="gmail_quote">- Gavin</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br>
</div>
<div class="gmail_quote">On Thu, Apr 12, 2012 at 5:50 PM, Gavin Peters (蓋文彼德斯) <span dir="ltr"><<a href="mailto:gavinp@webkit.org" target="_blank">gavinp@webkit.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Link Prerendering is a feature of chromium to load entire web pages ahead of navigation. The feature has been enabled in our release branch for some time, and prerender links are found on many web sites, and are emitted by Google Web Search for first results sometimes. To learn more about prerendering, see <a href="https://developers.google.com/chrome/whitepapers/prerender" target="_blank">https://developers.google.com/chrome/whitepapers/prerender</a></div>
<div><br></div><div>I'm working on removing <link rel=prerender ...> loads from the main resource loading path, and instead giving the platform a prerendering interface. Right now, prerenders are a type of resource request. In the chromium port, our network stack catches the prerender loads, aborts them, and asynchronously launches a prerender. We've been having a really good experience with prerendering in chrome, and we're at the point where to help more sites adopt it, we need a better API; the load events are not quite right for prerenders, and prerenders are not quite network requests in many ways. Using a cachedresourceloader to fire off a load for a request that will not return data didn't quite make sense.</div>
<div><br></div><div>Reviews are still ongoing, but the first few steps of this API are being worked on at <a href="https://bugs.webkit.org/show_bug.cgi?id=82478" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=82478</a> , and in <a href="https://github.com/gavinp/git.webkit.org/pull/2" target="_blank">https://github.com/gavinp/git.webkit.org/pull/2</a> [1]. Please, follow along if you're interested. There's a corresponding chrome CL tracking this api at <a href="http://codereview.chromium.org/9875026/" target="_blank">http://codereview.chromium.org/9875026/</a> , however that CL is not quite as up to date. I should update it in the next day or two, though.</div>
<div><br></div><div>This first set of changes lets prerendering launchers signal that they want a prerender to be dropped, simply by removing the link element from the document. A separate signal is sent to the prerendering platform when the page is navigated away from. As well, prerenders are now sent to the platform fragment clean, and the code path doesn't include things like a cached resource loader, which for a prerender didn't really make sense.</div>
<div><br></div><div>This API has been talked about at whatwg, at <a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035065.html" target="_blank">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035065.html</a> , and <a href="http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-April/035394.html" target="_blank">http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-April/035394.html</a> .</div>
<div><br></div><div>- Gavin</div><div><br></div><div>[1] I'm very happy with how a github pull request lets me easily show a change that has a lot of plumbing like this in layers. The interface for this aspect of it is great.</div>
</blockquote></div><br>