continued: Common-VFS proposal

Philippe Fremy phil at freehackers.org
Tue Jan 25 21:07:49 EET 2005


	Hi,

nf2 wrote:

> 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 
very slow).

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 
both corrects).

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[3]. 
> 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".

	regards,

	Philippe



More information about the xdg mailing list