- From: Glenn Maynard <glenn@zewt.org>
- Date: Mon, 17 Jan 2011 16:41:47 -0500
On Mon, Jan 17, 2011 at 4:34 PM, Ryosuke Niwa <rniwa at webkit.org> wrote: > On Mon, Jan 17, 2011 at 1:25 PM, Glenn Maynard <glenn at zewt.org> wrote: > >> On Mon, Jan 17, 2011 at 4:15 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: >> >> > If nothing else, I'm thinking things like "I would like to buffer up >> this >> > 3-hour-long-video so I can watch it on the plane, where my network >> bandwidth >> > will be precisely 0". Definitely as use case I've had. >> > >> >> That's an important use case, but it feels like a very different one. If >> you want to download hours of video for playing offline, you don't want to >> store that in a transient read-ahead buffer--you want to store it >> persistently on the disk, so it's not lost if a tab is closed, cache is >> cleared, etc. It sounds more like a FileAPI use case than a buffering >> parameters one. >> > > I disagree. If we don't address this use case, users can't watch videos > offline unless content providers explicitly provide such a mechanism using > File API, which will undermine usability significantly. > Maybe so, but the read-ahead buffer doesn't seem like a sensible place to address this. If I download a 3-hour video for a plane, it's not acceptable for that video to no longer be available if I restart my computer or close a tab. -- Glenn Maynard
Received on Monday, 17 January 2011 13:41:47 UTC