[webkit-dev] NetworkProcess / NetworkThread in the UIProcess

[Brady Eidson]

On Feb 12, 2013, at 12:00 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> 
> On Feb 12, 2013, at 8:28 AM, Zeno Albisser <zeno at webkit.org> wrote:
> 
>> 
>> On Tue, Feb 12, 2013 at 5:01 PM, Balazs Kelemen <kbalazs at webkit.org> wrote:
>> 
>> You also need IPC because the NetworkProcess serves the needs of the web process. Could you describe why a network thread in the UI process fit your needs bettter? Is it to support API's related to networking or does it have other advantages?
>> 
>>  
>> Yes, that was slightly ambiguous. Let me rephrase that.
>> Currently the IPC for the NetworkProcess is setup by ChildProcess::initialize(). Since we would not need to create a whole new process in our case, we would just spin of a thread and create the appropriate IPC connections ourselves.
>> That could be an implementation detail of our NetworkThread implementation. For prototyping i even reused the whole ChildProcess code with a few minor changes. But it would feel wrong to have instances of ChildProcess in something that is a thread of the same process.
>> 
>> One of the main advantages of having networking in the UIProcess for our port is, that we could support some features such as Application URL Schemes without going through the WebKit2 API.
>> This is a very Qt specific use case, that IMHO does not fit very nicely into the rest of the WebKit2 API. It is Qt specific because Qt makes heavy use of qrc files to embed content. And Application URL Schemes was the solution to allow for qrc content in a QQuickWebView. 
> 
> Is this just for the qrc URL scheme specifically? If so, why not just teach the NetworkProcess how to handle "qrc:"? Using a thread instead of a process sounds like overkill just to solve that one problem.

We already support custom schemes on Mac by proxying the loading from the networking process to the UI process.

For the Mac this is done in terms of NSURLProtocol.  You could provide your own implementation of the port-specific bits of CustomProtocolManager and CustomProtocolManagerProxy.

Thanks,
~Brady

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130212/7c308280/attachment.html>