Common VFS: GKIO experiment
elanthis at awesomeplay.com
Wed Dec 8 02:42:27 EET 2004
On Wed, 2004-12-08 at 01:12 +0100, nf wrote:
> Hi lists! (xdg, gnome-vfs, kde-core)
> In order to find a way out of this situation, i would like to start an
> experiment: To write a (KDE/C++) wrapper to Gnome-VFS which looks and
> acts like the KIO-API - "GKIO". Then write a number of test-cases, which
> test the GKIO-API for KIO requirements and compatibility. Once this
> tests work, i want to try plugging GKIO into kde-core libs (instead of
> original KIO code).
As an experiment that sounds fine. For a long-term solution, I don't
think that's workable. It'd probably be better (long-term) to develop
an independent, clean, highly tested (i.e. not buggy as all hell like
gnome-vfs) framework that can be reused by GNOME, KDE, and other desktop
Other benefits of said library, if designed right, might be things like
being able to LD_PRELOAD the library into apps using the normal
UNIX/ANSI file I/O commands to operate on VFS shares. Imagine being
able to just type in "less ftp://server/somefile" in your shell, or
"sort myfile > dav://fileserver/user/myfile" or whatever. This wouldn't
work for certain classes of apps without kernel support, I imagine
(chdir using apps, for example), but for many it would work and be
The architecture for framework would likely require a daemon (launched
on demand, on login using PAM session handling support, or whatever)
which clients interacted with for non-local URIs. That would also allow
caching and connection sharing/re-use for protocols that support it,
which would improve performance a good deal.
For cases where user-interaction is required (password prompts, etc.) a
D-BUS setup could allow a desktop client to listen for requests, prompt
the user, and return the entered information to the daemon.
The actual API should be designed first, though. Blindly mimicing the
UNIX/ANSI file I/O semantics is silly.
More information about the xdg