dvfs api and toolkits
jamiemcc at blueyonder.co.uk
Tue Apr 5 04:33:17 EEST 2005
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
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
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.
More information about the xdg