Also, in many cases the HTTP cache may not have enough space to store a downloaded movie, for example.
But more importantly, it seems to me that relying on the browser's internal magic for this is error prone. For example, the video player reusing the same URL as the one being passed to background cache cannot predict whether the playback will actually be successful. How about giving the programmer the ability to do this in a controlled manner? Strawman: could we provide a way to create a stream for an ongoing request? On 2016-09-07 2:17 PM, Ben Kelly wrote: > I wrote a test using fetch() that seems to suggest we don't re-use > in-progress requests at the http cache level. > > (Note, this downloads about 200MB... don't click on your mobile.) > > https://people.mozilla.org/~bkelly/fetch/http-cache/ > > On Wed, Sep 7, 2016 at 1:45 PM, Andrew Sutherland < > asutherl...@asutherland.org> wrote: > >> There's a proposal at https://github.com/jakearchibald/background-cache >> for enabling persistently-tracked uploads/downloads in the background. It >> might change names to background-fetch. >> >> I'm interested in getting some informed feedback about the following >> use-case on https://github.com/jakearchibald/background-cache/issues/3 >> >> A motivating use-case is for a site that wants to download movies/podcasts >> in the background and keep them around for offline purposes. Once the file >> is downloaded, it seems clear that the (ServiceWorker [DOM]) Cache API[1] >> is a great place to store the result. What's less clear is how best to >> handle allowing the user to begin watching the movie when the download is >> still in-progress. A potential straw-man is: >> >> * Start the download with background-fetch >> * Use the background-fetch API to track the status of the download. When >> there's "enough" downloaded, start playing the video via its online URL >> with the confidence that the netwerk cache2 can unify the two requests as >> much as possible. >> * When the download completes, stick the movie in the DOM Cache API and >> use Cache-furnished Responses for all future playback requests. >> >> The greatest concern right now is around range requests and redundantly >> downloaded data. We've seen interest in the Service Worker repo issues for >> the ability to track/match in-flight fetch requests[2] that I hope should >> be entirely mooted by the HTTP cache. Depending on the HTTP cache until >> the download is complete ideally avoids redundant downloads, but it would >> be great to have reassurance and an understanding of how a background-fetch >> download mechanism might interact with the HTTP cache. Could the download >> entirely use the HTTP cache for storage with the cache entries pinned to >> avoid eviction until the download notification extendable event completes? >> >> Andrew >> >> 1: https://w3c.github.io/ServiceWorker/spec/service_worker/ >> index.html#cache-objects >> 2: https://github.com/w3c/ServiceWorker/issues/959 >> >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
