Common VFS: GKIO experiment

[Sean Middleditch]

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
environments.

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
rather convenient.

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.