KDE is not an OS platform... (And neither is Gnome)

[nf2]

On Fri, Oct 30, 2009 at 10:23 PM, Kevin Krammer <kevin.krammer at gmx.at> wrote:
> On Friday, 2009-10-30, Michael Pyne wrote:
>
>> I think a saner alternative to integrating GVFS into KIO would be to
>>  support the IO-transfer API in use (assuming they use an out-of-process
>>  model
>
> Yes, they do. GVFS mount daemon are separate processes, shared between
> applications accessing the same protocol.
>

Actually in most cases they are launched per remote resource (like
protocol://user@server). When I, for instance, connect to my own FTP
server and ftp.kde.org, i can see two gvfsd-ftp processes running. But
for HTTP there is only a single gvfsd-http...

>
>> Really making something like FUSE that "backend API" would probably be best
>> long-term, except that it wouldn't work under Windows or OS X (and possibly
>> BSD?)
>
> The other way around, which is what GVFS is doing, sounds to be a better
> approach.
> Applications directly dealing with GVFS can reap the full benefit of the
> architecture, applications still living in POSIX world can use the same data
> through the FUSE mounts of GVFS.
>
> The only thing missing is currently a Qt technology stack based client library
> for GVFS, just like there is not GObject technology based on for KIO slaves.
>

I guess you meant a pure Qt implementation, using QDBus...

Yes, that sounds like an exciting undertaking for making this a true
"service oriented
infrastructure". And it's all D-Bus anyway, plus a binary socket
protocol for GInputStream/GOutputStream...

But probably not that essential for actually using it (at least in an
ioslave) , as just linking current C-client doesn't look like a big
burdon - it just uses some libraries from the GLib package plus
libdbus-1 (it doesn't even require the libdbus-glib bindings).

Here is a list of the current dependencies:

* The public interfaces:

$ ldd /usr/lib/libgio-2.0.so
	linux-vdso.so.1 =>  (0x00007fffd2ffe000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f21caa43000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f21ca83f000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f21ca63a000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f21ca375000)
	libpcre.so.3 => /lib/libpcre.so.3 (0x00007f21ca145000)
	libselinux.so.1 => /lib/libselinux.so.1 (0x00007f21c9f28000)
	libc.so.6 => /lib/libc.so.6 (0x00007f21c9bb6000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f21caf27000)


* The GVFS implementation of those interfaces (GVFS client part):

$ ldd /usr/lib/gio/modules/libgvfsdbus.so
	linux-vdso.so.1 =>  (0x00007fffe6dfe000)
	libgvfscommon.so.0 => /usr/lib/libgvfscommon.so.0 (0x00007f6ade885000)
	libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x00007f6ade648000)
	libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007f6ade3ca000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f6ade184000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f6addebf000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6addca2000)
	libc.so.6 => /lib/libc.so.6 (0x00007f6add930000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f6add72c000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f6add527000)
	libpcre.so.3 => /lib/libpcre.so.3 (0x00007f6add2f7000)
	libselinux.so.1 => /lib/libselinux.so.1 (0x00007f6add0db000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6adecdc000)


* The code shared between the client and the mount-daemons:

$ ldd /usr/lib/libgvfscommon.so.0
	linux-vdso.so.1 =>  (0x00007fff3c1fe000)
	libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x00007f5133c99000)
	libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007f5133a1c000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f51337d5000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f5133510000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f51332f4000)
	libc.so.6 => /lib/libc.so.6 (0x00007f5132f81000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f5132d7d000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f5132b79000)
	libpcre.so.3 => /lib/libpcre.so.3 (0x00007f5132948000)
	libselinux.so.1 => /lib/libselinux.so.1 (0x00007f513272c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f513410e000)


Technically I can only see a little problem, because GVFS needs some
client side "intelligence" for mapping URIs to mount daemons. For some
protocols this can't be done in a standard way (http, webdav and
smb-shares), therefore there are specific GVfsUriMapper
implementations. This code would have to be shared of course.


Norbert