dvfs api and toolkits

Sean Middleditch elanthis at awesomeplay.com
Sat Apr 9 23:33:29 EEST 2005


On Sat, 2005-04-09 at 20:43 +0000, Nate Nielsen wrote:
> Sean Middleditch wrote:
> > Atomic whole-file writes are thus possible on pretty much every file
> > system and protocol I know of in major use without needing any form of
> > locking.  
> 
> That's wonderful, and it's an elegant solution to one particular problem.

And it's a solution that should, in my opinion, *continue* working for
that problem.

> 
> > If we try to emulate seeking in HTTP by re-requesting files,
> > we make that impossible without adding locking.  If we just tell apps to
> > download the files and seek on the local cache then we will still retain
> > the atomic write capability. 
> 
> 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.
-- 
Sean Middleditch <elanthis at awesomeplay.com>




More information about the xdg mailing list