Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case

[Robert O'Callahan]

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

[Ralph Giles]

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

[Ehsan Akhgari]

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

[Robert O'Callahan]

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

[Ehsan Akhgari]

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

[Ben Kelly]

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

netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case

[Andrew Sutherland]

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