dvfs api and toolkits

[Avery Pennarun]

On Sat, Apr 09, 2005 at 04:33:29PM -0400, Sean Middleditch wrote:

> > This seems like a good idea at first, but it breaks down when files are
> > large. Let's say I open a movie file (let's say, for example, over a
> > local network) and seek halfway through it. Does the entire file (ie:
> > hundreds of megabytes worth of data need to be cached before my the
> > application stops saying "buffering...".
> 
> That isn't how D-VFS works.  I really am wondering where people keep
> getting that impression, it's the complete opposite of pretty much every
> example I've given so far.
> 
> You can read the file incrementally *while* the cache is being made.
> Your app is given the stream of bytes as the download progresses, which
> it can process as it sees fit.

Movie players are, however, a good example of where seekability might be
important.  Imagine you're halfway through playing a movie and your computer
crashes.  You reboot, and to resume halfway through the movie you...
download the first half over again?  Not too pretty.

That said, this is a pretty special case.  Perhaps movie players need to
implement their own client with all the features they need (for example,
it's okay to actually lose frames out of the middle of a video; it's much
better to do that than to stop and wait for them to retry).  Or perhaps our
ability to think of a counterexample before coding even starts is a good
sign that a feature is missing here.

Also notable is that it really doesn't matter if the file changes out from
under you when you seek around in a video, so atomicity and locking are
pretty irrelevant.  You'll still be in approximately the right place.

Have fun,

Avery