[Portland] PortlandVFSProposal

[nf2]

Bastian, Waldo wrote:

>>[Disclaimer: I haven't actually read through the code I'm about to
>>pontificate about.]
>>
>>I always thought the Gnome and KDE VFS's were
>>needed only because the kernel lacked three crucial
>>features:
>>1) safe unprivileged mounts
>>(but it's probably getting those; see http://lwn.net/Articles/160906/ )
>>2) per-user mounts
>>(but it's getting those; see http://lwn.net/Articles/159077/ )
>>3) an easy way to add new filesystem types
>>(which we have now with fuse).
>>    
>>
>
>KDE's KIO has been written to handle
>1) Slow unreliable (read: remote, read: NFS mounted) filesystems.
>2) I/O related user interaction
>
>Wrt 1. By using an asynchronous out of process approach, the application
>is not affected by network delays and allows to remain responsive.
>Although this could nowadays be achieved with in-process threading as
>well, separate processes are still considered preferential in order to
>maintain stability by separating the application from protocol handling
>code. E.g. the protocol handler (KIO process) can crash or be killed
>without negative impact on the application (and without memory leaks).
>
>A key benefit of the KIO approach is that it allows protocol handlers to
>be written using synchronous code paths, making it easy to use a variety
>of existing protocol specific libraries.
>
>I think hiding from applications the fact that data resides across a
>network, as fuse attempts to do, is a fundamental wrong approach since
>this aspect has a major impact on the end-user experience. In particular
>all kinds of assumptions that application developers tend to make about
>disk access start to break down. KIO replaces the expectations that
>application developers have wrt a local file system with a new set of
>expectations applicable to KIO allowing application developers to design
>their application around this new set of expectations.
>
>There is a very nice Sun technical report that touches on this issue in
>a slightly different context:
>http://www.sunlabs.com/techrep/1994/abstract-29.html
>
>Cheers,
>Waldo
>_______________________________________________
>  
>
The only problem about KIO is that it has not been designed as common 
infrastructure (in a toolkit and desktop independent way).

Do you think it would make sense to rewrite KIO in C and to wrap a 
synchronous and async API around the slave protocol (that it can serve 
both the KIO::Jobs and the Gnome-VFS API.

Regards,
Norbert