Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case
On Thu, Sep 22, 2016 at 10:47 AM, Ehsan Akhgari wrote: > My point was more about whether there's something useful that can be > done with partially downloaded files other than media files. Not all > file formats lend themselves to be used before the full file is > available. I don't know how prevalent the ones that do are in practice... > Also, for this to matter, it has to be the *browser* (or at least something other than the service worker's Web application) consuming the results of the download. If the Web application is consuming the results of the download, it could presumably be altered to consume chunks delivered from the service worker. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case
On 2016-09-21 6:31 PM, Ralph Giles wrote: > On Wed, Sep 21, 2016 at 3:19 PM, Ehsan Akhgari > wrote: > >> Good point, which brings us to this question: is media playback the only >> use case for using the in-progress downloads? > > This in-progress issue is mostly about the download size, so I can > imagine the same thing happening with other large files. I guess > that's usually zip files of whatnot, software packages, maybe large > scanned documents. Wanting serial access is most common with media but > it could apply to those cases as well. Whether they're worth the work > of supporting, I don't know. My point was more about whether there's something useful that can be done with partially downloaded files other than media files. Not all file formats lend themselves to be used before the full file is available. I don't know how prevalent the ones that do are in practice... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case
On Wed, Sep 21, 2016 at 3:19 PM, Ehsan Akhgari wrote: > Good point, which brings us to this question: is media playback the only > use case for using the in-progress downloads? This in-progress issue is mostly about the download size, so I can imagine the same thing happening with other large files. I guess that's usually zip files of whatnot, software packages, maybe large scanned documents. Wanting serial access is most common with media but it could apply to those cases as well. Whether they're worth the work of supporting, I don't know. -r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case
On 2016-09-21 4:35 PM, Robert O'Callahan wrote: > On Thu, Sep 8, 2016 at 5:45 AM, Andrew Sutherland < > asutherl...@asutherland.org> wrote: > >> 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. >> > > It seems to me that authors could solve this using MSE for playback and > breaking the file into chunks. Good point, which brings us to this question: is media playback the only use case for using the in-progress downloads? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case
On Thu, Sep 8, 2016 at 5:45 AM, Andrew Sutherland < asutherl...@asutherland.org> wrote: > 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. > It seems to me that authors could solve this using MSE for playback and breaking the file into chunks. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case
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
Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case
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