On Feb 12, 2013, at 8:28 AM, Zeno Albisser <[email protected]> wrote: > > On Tue, Feb 12, 2013 at 5:01 PM, Balazs Kelemen <[email protected]> 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. Regards, Maciej
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
