<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 10, 2014 at 12:28 PM, youenn fablet <span dir="ltr"><<a href="mailto:youennf@gmail.com" target="_blank">youennf@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I looked at the Networking process recently and am wondering what is<br>
in scope/out of scope of this process.<br>
<br>
Currently, the networking process is used to load resources from:<br>
- URLs resolved using platform specific libraries (CF, libsoup...),<br>
including data URLs<br>
- Blob URLs<br>
The networking process is not used for (at least):<br>
- appcache resources URLs<br>
- archive resources URLs<br>
<br>
Two options come to mind:<br>
1. Use networking process for all URLs that require actual networking.<br>
That would mean moving data & blob URL handling within WebProcess,<br>
probably unifying this loading with appcache/archive resource loading.<br></blockquote><div><br></div><div>A load should go to the network process if it needs to do actual networking. Web processes should not need that capability at all (there are a few things that still require this at the moment I think). Another reason might be a case where multiple web processes need to see the same view of some non-network resources.</div><div><br></div><div>Otherwise it makes sense to handle loads as close to the request source as possible to minimize overhead and complexity. At least data: could be handled in the web process just fine. I think blob: too.</div><div><br></div><div><br></div><div> antti</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Use networking process for all URLs. That would mean moving<br>
appcache/archive resource loading into Networking process at some<br>
point.<br>
<br>
Any thoughts?<br>
<br>
Regards,<br>
Youenn<br>
</blockquote></div><br></div></div>