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