dvfs api and toolkits

[apenwarr at nit.ca]

On Mon, Apr 04, 2005 at 10:47:00PM -0400, Sean Middleditch wrote:

> > I think seeking is needed for other things in documents - PDF's perhaps?
> 
> And this is why I'm looking for input from application authors and not
> discussion on daemons and protocols.  ;-)  *Do* PDF readers do seeking
> around in files, or read the whole things into memory?  Do they want
> seeking?  What about all the very useful file systems that *don't* offer
> seeking support, like FTP - these apps should work on those file
> systems, and caching is something I'd REALLY want to avoid if at all
> possible - if it's something only one or two apps really need, I'd
> rather just make those apps themselves do the caching, for example.

PDF readers definitely seek around in files, as do ps viewers, mp3 players,
dvd players, some word processors (you can't load an entire book, including
illustrations, into RAM at once).  You definitely need to support this.

However, a valid way of supporting this in almost all cases is to just send
the whole file to the client, then let the client store it on disk and seek
around all he wants.  It's usually a matter of not wasting too much physical
RAM, not of too much transfer time.  (Mostly if you open an mp3 file or pdf,
you're going to need to download most of the file anyhow.)

So it sounds like the system as currently designed can mostly handle it. 
Don't think of the local copy of the file as a "cache" - just as the
"working version." (Of course, a cache is useful anyway for lots of reasons. 
The most obvious one is that I "preview" a document in Nautilus, then want
to open it in gimp or something.  You're not going to make me download it
*twice*, are you??)

Have fun,

Avery