Re: [webkit-dev] Streams API
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
Re: [webkit-dev] Streams API
On Sun, Nov 2, 2014 at 2:56 PM, youenn fablet wrote: > Meaning that only the fetch API would at some point support streams? > If so, I wonder why we should postpone a small but useful feature to a > nice but future API. I suspect there will be many APIs that support streams. It's been a sorely missing building block. And fetch() is not a future API. It's being implemented now in both Blink and Gecko. -- https://annevankesteren.nl/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Streams API
Meaning that only the fetch API would at some point support streams? If so, I wonder why we should postpone a small but useful feature to a nice but future API. 2014-10-31 8:48 GMT+01:00 Anne van Kesteren : > On Fri, Oct 31, 2014 at 12:02 AM, youenn fablet wrote: >> I would like to add support for the streams API, starting >> with readable streams and their integration with XHR and loaders. >> This work is expected to happen behind a flag. > > There's no planned integration with XMLHttpRequest. > > > -- > https://annevankesteren.nl/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Disk cache
El sáb, 01-11-2014 a las 20:43 +0200, Antti Koivisto escribió: > On Sat, Nov 1, 2014 at 10:13 AM, Carlos Garcia Campos > wrote: > El vie, 31-10-2014 a las 19:02 +0200, Antti Koivisto escribió: > > Hello, > > > > > > I'm planning to add an experimental HTTP cache > implementation to > > WebKit (https://bugs.webkit.org/show_bug.cgi?id=30322). > > Great news! > > > The main motivations are: > > > > > > - Improving performance by bringing the cache closer. For > example we > > can serialize WebKit response objects directly instead of > converting > > to/from platform types. > > - Making future innovation around caching easier. Closer > coordination > > between cache and WebKit opens new optimization > possibilities. > > > > > > The cache lives in the network process. Most of the code is > > cross-platform. The storage backend uses libdispatch IO > though it > > wouldn't be hard to add a generic posix one too. > > Why is it limited to the network process? wouldn't it be > possible to use > it also in the web process when shared secondary process model > is used? > > > The cache ties to NetworkResourceLoader which lives in the network > process. In principle it would be possible to integrate with the web > process side resource loader too. However I don't want to support > multiple configurations during development. > > > It would be good if all WK2 ports would eventually switch to using the > network process. The current multitude of configurations makes > networking related code more confusing and less hackable than it needs > to be. The GTK+ port supports the network process, but it's only used when multiple secondary process model is used. Some applications prefer the single shared secondary process model, and even some of the browser users change the default process model of epiphany to single web process because it requires fewer resources. So, we could either integrate the cache with the web process loader, or use the network process unconditionally for all process models. I think for many simple applications a single web process is the most efficient model, though. > > > >antti > > > > > > The code will be behind NETWORK_CACHE feature flag. > > > > > > > > > > antti > > ___ > > 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
