waldo.bastian at intel.com
Mon Jan 9 19:10:07 EET 2006
>[Disclaimer: I haven't actually read through the code I'm about to
>I always thought the Gnome and KDE VFS's were
>needed only because the kernel lacked three crucial
>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:
More information about the Portland