dvfs api and toolkits

[Sean Middleditch]

On Mon, 2005-04-04 at 23:03 -0400, apenwarr at nit.ca wrote:
> 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.)

That is what I was leaning towards.  Possibly providing some API for
"grab this file, put it in a temporary file and give me a POSIX file
handle for it, and notify me of its download completion status."

Some backends might have relatively efficient support for seeking, and
it might be possible to design the API in such a way that it can
transparently support either native seek support or local-copy
emulation.  Doing that could get tricky, though, in some cases - what if
you open a large file on a backend that doesn't handle seeking but just
stream it in?  Should the system try to create the temporary copy
anyhow, or should the API require the developer to explicitly state, "I
want this file to be seekable" ?

> 
> 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??)

This is a good point.  I think it depends somewhat on the file system.
Certain file systems just aren't safe to cache files unless you grab the
whole things (and file manager previews for many file types don't need
to do this - video thumbnailing, for example) and others explicitly deny
it in some cases.

Caching is, as I believe should be mentioned on the wiki, on the places
I'm really unsure on in general.  Lots of issues to work out.
-- 
Sean Middleditch <elanthis at awesomeplay.com>