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

[nf2]

On Fri, Oct 30, 2009 at 9:54 PM, Michael Pyne <mpyne at kde.org> wrote:
> On Friday 30 October 2009 12:20:49 Benoit Jacob wrote:
>> I just would like to understand if there's a real reason anymore for
>> not letting KIO/GVFS go through the native VFS on Linux (and perhaps
>> other *nix). Again, on other exotic platforms, the statu quo seems
>> good enough.
>
> There's no reason we can't (just modify the kioslave for #if Q_OS_FOO ;)
>
> 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, if they
> don't we can just fork() kio-gio bridges though.  I wonder if this is how
> nf2's bridge works? :)
>

The kio-giobridge is just implemented as an ioslave and uses the
synchronous API of GIO (Gio provides both, sync and async). Therefore
it's being forked already. :-)

As there is no extra layer between the GIO API and the GVFS client
side part (which is talking to the backends), i didn't see much point
in circumventing the the GIO API. For instance GDaemonFileInputStream
is just an implementation of the abstract base class GInputStream, and
it's returned when you call g_file_read() on a remote file. It will
directly read the file-data from an IPC socket.

Of course that's chaining two IPC bridges:

KIO -> Kio-Giobridge ioslave -> GVFS Mount Daemon.

Which is very similar to accessing a FUSE filesystem with KIO:

KIO -> kio_file -> FUSE process

There might be ways to make KIO talk to the GVFS Mount Daemon
directly, but that would mean a 100 times more work, with no guarantee
that the outcome would be significantly faster (as this is for
network-protocols).


> Once we can support KIOSlaves and GIO from KIO then perhaps we can standardize
> a IO virtualization interface on XDG so that the actual IO backends of KIO and
> GVFS could be used interchangeably.  (This also allows for the backends to be
> implemented in languages other than C, which is good IMO).

That's not easy i guess, because the SlaveBase and GVfsBackend - the
base classes for implementing protocol handlers -  are not that
similar.

GvfsBackends, can recieve calls from multiple applications, reading
files in parallel and so on. The operations are atomic, Open, Read,
Close are processed as separate "daemon jobs" (the daemon side
representation of an operation).

For instance there are two methods you can override for reading a
chunk of a file:

GVfsBackend::try_read(), when the oparation can be handled instantly,
or in an async way.

GVfsBackend::read(), when you want to handle it in a blocking way
(scheduled in a worker thread).


Nevertheless, implementing GVfsBackends in C++ shouldn't be a problem.
I would like to try to port some ioslaves over, but I guess I only
feel motivated if i can get a little bit of acceptance for the whole
undertaking (A yellow light, instead of a red one ;-). And of course a
lot of KDE specific protocols don't need to be ported.

Regards,
Norbert