continued: Common-VFS proposal
phil at freehackers.org
Tue Jan 25 21:07:49 EET 2005
> A shared backend in KIO style (async get/put only) won't work. The
> reason is that with async get/put you give up "flow-control".
My understanding was that the VFS thing is mainly to access network
documents, with the usual consequences that most of the times, these
accesses are slow and that sometimes, the document is big (access very
Examples that comes to my mind are ftp, http, ssh and samba. In all
these cases, you do not want to block your application until the end of
the document is available, but you want to display the progress of the
document downloading if the document access is not immediate.
So an async VFS layer makes perfect sense. Can you provide use cases
where a synchronised VFS layer makes more sense ?
If the document is immediately available, nobody cares whether it was
fetched asynchronously or synchronously. If you are going to perform
complex operations on the document, in any cases, you need to download
it first and you can work with a full POSIX api on a local file.
Your only argument so far for sync VFS has been that it is compatible
with POSIX, and that event loop integration is complicated (which are
I am under the impression that if you provided a sync VFS access, all
the applications are going to wrap an async access on top of it because
that's what they need. At least that's what ftp, http and ssh clients
would immediately do.
Besides, the fact that both KDE and Gnome VFS developers seem to
disagree with your design does not sound promising for its possible
integration into any of the major desktops.
> With the consequence that you can easily wrap a KIO style system (async
> get/put only) around a POSIX style system
> Async behavior can be easily achieved with threads in the VFS client.
> It's an "add on" and not a core feature of a VFS.
I think you over use the word "easily". Experience reveals that it is
not a friend of the word "threads".
More information about the xdg