dvfs api and toolkits

[Sean Middleditch]

On Tue, 2005-04-05 at 02:04 +0100, Jamie McCracken wrote:
> > 
> >>more flexibility then the high level document interface which might not 
> >>be appropriate for some things (EG log files where you want to append 
> >>text without reading the whole file into memory, mime type sniffing 
> > 
> > 
> > Don't use D-VFS for log files.  D-VFS isn't for log files.  It's not for
> > configuration files.  It's not for application data files (ie, stuff
> > in /usr).  It's for documents.  Maybe we should call it Document-VFS
> > instead of Desktop-VFS.  ;-)   
> 
> The other big problem with this is video files - in particular huge 
> ones. Using your document API loading a 1GB avi file would need 1GB of 
> RAM which is of course completely barmy. Now video files are documents 
> are they not? And they can be on non local media so theres another good 
> reason for making the document API a subset whilst providing alternate 
> methods for streaming files chunk wise.

No, it wouldn't.  Don't know where you got that idea from, it's in stark
contrast to the examples I've given out previously and comments on the
wiki page.

The APIs work similar to POSIX in that you get chunks of the file
streamed to you as you read.  With the async API it's delivered in
callbacks while with the sync API its read in a loop.  Either way, you
get a chunk, process it, and can then throw it out if you don't need it
anymore.  Playing a streaming video should work pretty flawlessly with
D-VFS.  Jumping around in a video might be a challenge.

The API will probably support seeking in files, but I want to highly
discourage developers to use that feature unless absolutely necessary,
because many protocols don't support it at all.

> 
> jamie.
> 
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>