Re: [webkit-dev] Streams API

2014-11-10 Thread youenn fablet
I opened a meta-bug at https://bugs.webkit.org/show_bug.cgi?id=138561
I also plan to close bugs related to the previous stream API
proposal (https://bugs.webkit.org/show_bug.cgi?id=110194 and
https://bugs.webkit.org/show_bug.cgi?id=110558).

2014-11-03 7:57 GMT+01:00 Benjamin Poulain benja...@webkit.org:
 It looks like nobody has raised any concern against Streams API. We even got
 positive feedback from Anne. :)

 I have two concerns:
 1) You have many patches waiting for review. I think you need to get better
 communication channels with reviewers in order to iterate over your patches
 faster. It is unfortunate but getting complex patches reviewed in WebKit
 requires poking reviewers directly. Since you work on the network stack, I
 suggest asking Alexey (ap) and Pratik (psolanki) on IRC, they can help with
 reviews or suggest other reviewers.
 2) Streams is a large spec and it touches platform code. Please be careful
 with stability, make more tests than reasonable and #ifdef everything.

 I suggest the flag name ENABLE_STREAMS_API, I find ENABLE_STREAMS a bit
 too generic.

 If you open a meta bug, please send the bug number to the mailing list for
 reference.

 Good luck :)
 Benjamin


 On 10/30/14, 4:02 PM, youenn fablet wrote:

 Hi all,

 I would like to add support for the streams API ([1], [2]), starting
 with readable streams and their integration with XHR and loaders.
 This work is expected to happen behind a flag.

 Regards,
 Youenn

 [1] https://github.com/whatwg/streams
 [2] http://www.w3.org/TR/streams-api/
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Networking process scope

2014-11-10 Thread youenn fablet
Hi,

I looked at the Networking process recently and am wondering what is
in scope/out of scope of this process.

Currently, the networking process is used to load resources from:
- URLs resolved using platform specific libraries (CF, libsoup...),
including data URLs
- Blob URLs
The networking process is not used for (at least):
- appcache resources URLs
- archive resources URLs

Two options come to mind:
1. Use networking process for all URLs that require actual networking.
That would mean moving data  blob URL handling within WebProcess,
probably unifying this loading with appcache/archive resource loading.
2. Use networking process for all URLs. That would mean moving
appcache/archive resource loading into Networking process at some
point.

Any thoughts?

Regards,
   Youenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Networking process scope

2014-11-10 Thread Maciej Stachowiak



Sent from my iPad

 On Nov 10, 2014, at 4:28 AM, youenn fablet youe...@gmail.com wrote:
 
 Hi,
 
 I looked at the Networking process recently and am wondering what is
 in scope/out of scope of this process.
 
 Currently, the networking process is used to load resources from:
 - URLs resolved using platform specific libraries (CF, libsoup...),
 including data URLs
 - Blob URLs

These categories of loading apply consistently regardless of context. They 
interpret URLs globally. data: and blob: are specific URL schemes, and not 
especially different in this regard, though it is true they can be loaded 
without I/O.

 The networking process is not used for (at least):
 - appcache resources URLs
 - archive resources URLs

These categories are content-specific. App cache and web archives can redefine 
the meaning of a URL and substitute an alternate resource, but this only 
applies to a particular page load.

I am not sure if the line drawing intentionally reflects this distinction, but 
I think it is a reasonable line to draw. 

It might make sense to change where the line is drawn. I am curious what people 
more involved in the networking code think.

 
 Two options come to mind:
 1. Use networking process for all URLs that require actual networking.
 That would mean moving data  blob URL handling within WebProcess,
 probably unifying this loading with appcache/archive resource loading.
 2. Use networking process for all URLs. That would mean moving
 appcache/archive resource loading into Networking process at some
 point.
 
 Any thoughts?
 
 Regards,
   Youenn
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Networking process scope

2014-11-10 Thread Antti Koivisto
On Mon, Nov 10, 2014 at 12:28 PM, youenn fablet youe...@gmail.com wrote:

 Hi,

 I looked at the Networking process recently and am wondering what is
 in scope/out of scope of this process.

 Currently, the networking process is used to load resources from:
 - URLs resolved using platform specific libraries (CF, libsoup...),
 including data URLs
 - Blob URLs
 The networking process is not used for (at least):
 - appcache resources URLs
 - archive resources URLs

 Two options come to mind:
 1. Use networking process for all URLs that require actual networking.
 That would mean moving data  blob URL handling within WebProcess,
 probably unifying this loading with appcache/archive resource loading.


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.

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.


   antti


 2. Use networking process for all URLs. That would mean moving
 appcache/archive resource loading into Networking process at some
 point.

 Any thoughts?

 Regards,
Youenn

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev