Thomas Leonard wrote:

>
>In other words, I want ROX-Filer to use a VFS *interface* rather than any
>specific implementation (we already had to remove all the mc_* stuff after
>mc's VFS disappeared). But gnomevfs and kioslaves are both fine as
>implementations, and we're not pushing for another one.
>
>  
>
While i think this pluggable VFS interface is a good idea, it won't be easy:

1) The interface has to be a superset of Gnome-VFS API and the KIO Api 
(methods and callbacks).
AFAIK KIO has no synchronous API. You can look at the fuse_kio 
implementation to see how a synchronous wrapper for KIO could look like:

http://cvs.freedesktop.org/ctd/ctd/fuse_kio/

The ugly thing about that is, that it needs to create temporary files 
for mapping the synchronous open-read/write-close scheme to the KIO 
async get/put+callbacks scheme. It would probably be better to add 
synchronous calls to the internal KIO concept (in SlaveBase).

2) KIO needs a Non-GUI API (which exposes things like auth callbacks) 
behind its traditional KIO:: API.

3) You have to fix the main-loop problem (By adding a 
--with-glib-main-loop switch to Qt for instance).

The advantage of a pluggable VFS adapter would be that you could also 
plug a basic VFS (file: only) like you suggest and that the Qt GPL 
license would not hurt anymore when using KIO.

The interesting question is how the API would look like. I would expose 
the full manageability of internal VFS session objects (called 
"Virtual-Mounts" in my proposal) and general settings (like SMB 
workgroup, proxies) to the VFS clients for instance.

Norbert