On Mon, Jan 17, 2011 at 4:34 PM, Ryosuke Niwa <[email protected]> wrote:
> On Mon, Jan 17, 2011 at 1:25 PM, Glenn Maynard <[email protected]> wrote: > >> On Mon, Jan 17, 2011 at 4:15 PM, Boris Zbarsky <[email protected]> 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
