Some InjectedBundle magic in WebKitGtk ?

I don't think we need magic, we can just add custom IPC messages like we have done for other network features. I guess we just need to send a URI (or list of URIs) to the web process and call soup_session_prepare_for_uri() there.

you mean soup_session_prefetch_dns(). prepare_for_uri() is deprecated

Ah, I didn't know soup_session_prefetch_dns(). So, we could simply add webkit_web_context_prefetch_dns() with the same API than libsoup. I wonder how this affects "enable-dns-prefetching" setting in WebKit, though. I mean, if there's already a setting to do DNS prefetching, and WebKit already does it, woulnd't be enough to enable the setting? why do we need api for that?

the network process doesn't know what names you want to prefetch, so the web process has to tell it

Ok, after looking at wk code, the enable-dns-prefetching settings enable the DNS prefetch for parsed links, and it's indeed implemented using soup_session_prefetch_dns() in the soup backend. So we still need to add a way for the user to prefetch any hostname from the API. We could use the same soup api webkit_web_context_prefetch_dns(), although I wonder whether we need the callback with the result. To implement it in the WebProcess we can use DNS::prefetchDNS(), if we don't include the callback in the API, or soup_session_prefetch_dns() directly if we need to send back the result to the ui process.

(In reply to comment #6)
> Ok, after looking at wk code, the enable-dns-prefetching settings enable the
> DNS prefetch for parsed links, and it's indeed implemented using
> soup_session_prefetch_dns() in the soup backend. So we still need to add a way
> for the user to prefetch any hostname from the API. We could use the same soup
> api webkit_web_context_prefetch_dns(), although I wonder whether we need the
> callback with the result. To implement it in the WebProcess we can use
> DNS::prefetchDNS(), if we don't include the callback in the API, or
> soup_session_prefetch_dns() directly if we need to send back the result to the
> ui process.

We needed the callback because we are using dns prefetching throttling in order not to flood the network stack with tons of DNS resolutions that will slow down (and even cancel) the resolutions needed by the resources being loaded.

It isn't the result what we really want but the ack that the resolution is finished.

Yes, the callback is used in WebCore just to decrement the DNS request counter, but my question is about the API. Ephy still uses prepare_uri, so it doesn't receive any notification when the operation is done. Do the user of the WebKitGTK API need such information? should we use the gio async pattern for the api in such case?

Ah ok, regarding the API I don't think a client would need such kind of information unless it wants to implement something similar. One thing to consider in the implementation is that it would be nice to directly use WebCore's prefetching mechanism in order to have throttling instead of directly calling the libsoup method.

(In reply to comment #9)
> Ah ok, regarding the API I don't think a client would need such kind of
> information unless it wants to implement something similar. 

We all agree, Dan told me the same :-)

> One thing to
> consider in the implementation is that it would be nice to directly use
> WebCore's prefetching mechanism in order to have throttling instead of directly
> calling the libsoup method.

See comment #6:

"To implement it in the WebProcess we can use DNS::prefetchDNS(), if we don't include the callback in the API"

See https://bugs.webkit.org/show_bug.cgi?id=99695

Created attachment 236927 [details] [review]
Patch

Review of attachment 236927 [details] [review]:

OK.