dvfs api and toolkits

[Jamie McCracken]

Sean Middleditch wrote:
> 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.

 From your wiki you criticised POSIX and its reading of chunks of bytes 
so I assumed D-VFS would not have this :

"Traditional file APIs, such as POSIX, are based on a concept of reading 
and writing bytes. When you develop an application that reads a file 
with these APIs, your application is not truly written around the 
concept of reading the file; instead, it's written around the concept of 
reading chunks of bytes. The same goes for writing files. Additionally, 
these interfaces are very complex to use. Operations can be interrupted 
in the middle of their work, resulting in syscalls that can do only half 
of what you asked them to do. The random-access nature of the file 
system also results in a lot of complication in the entire design of the 
system.

While these APIs are very useful to certain classes of applications - 
database apps, for example - they are often far more complicated and 
detailed than your average desktop application needs. A desktop 
application saves and loads files. That is pretty much it. Your word 
processor loads a document, then saves it. Your text editor does the 
same. Your email client might save copies of message or attachments. 
Your web browser saves downloads. These types of applications save and 
load whole files as their basic file-level operation. Making these two 
operations as easy and efficient as possible will result in an API that 
is ideal for desktop-application usage. "


> 
> 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.  

Okay that wasn't clear before - I was under the impression the load 
method loaded the entire file into memory without forcing the client app 
to read chunks of bytes (as you criticised that in your wiki!).


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.

I think seeking is needed for other things in documents - PDF's perhaps?

Glad to see you are considering supporting this.

jamie.


> 
> 
>>jamie.
>>
>>