Kill KIO (was: Repositioning the KDE brand)

[nf2]

On Mon, Jul 13, 2009 at 10:59 AM, Jos Poortvliet<jospoortvliet at gmail.com> wrote:
>
> I'm not at home in the technical department, but I haven't seen any
> strong technical arguments. Is the GIO/GVFS system clearly superior to
> KIO, does it offer all the functionality and more with better
> performance and stability? If that's the case I would guess there
> wouldn't be so much resistance. If it sucks compared to KIO, what the
> heck were you thinking even proposing it?
>

Let's describe the major differences in design first. It's about
connection sharing and stateless vs. statefull.

* In KIO the daemon processes exist on per client basis. For every
application working on a certain FTP server there will be at least one
ioslave instance and one FTP connection. Thus if you list an FTP
directory in dolphin and in kwrites filechooser, there will be two
ioslaves and two FTP connections. If the FTP server limits the number
of connections, you might hit that limit. It's not really controllable
by the user, how long a connection lives. That's a matter of waiting
for the ioslaves idle timeout. A kind of stateless design. You never
know if you are still connected.

* In GVFS, daemon processes (which are called "mount daemons") are
instantiated per remote resource. For instance a certain user at server.
Every application beeing interestet in the same remote resource will
talk to the same mount daemon. Therfore in most cases only a single
connection to the remote side is necessecary as long as there are no
concurrent calls. The deamon process will live until you "unmount" it.
You don't have to type the password again as long as you don't unmount
(The mount appears in the list of drives and as desktop icon, just
like a CD or a USB stick).

I would describe the design of GVFS as somehow similar to FUSE. The
only difference is that calls don't go through the POSIX API but
through D-Bus for the signaling and a custom p2p socket protocol for
the payload data. That kind of circumvents the limitations of POSIX in
FUSE (cancellation, detailed error messages,...). The management of
the mount daemons lives in a kind of "master daemon" which is started
via D-Bus. Applications talk to the "master daemon" first, to look up
or instantiate a certain mount daemon.

Threads and connection pooling: Depending on the protocol, calls can
be put on different threads in the mount daemon. This is necessary for
instance for FTP, which doesn't have atomic read or write operations.
An entire file transfer is a single FTP operation. If there is a
concurrent operation, another thread and connection is needed in the
mount deamon. For SMB that's not necessary AFAIK, because calls into
libsmbclient are atomic reads and writes.

* Local file management: The GVFS deamons are only needed for remote
filemanagement. Local filemanagement is done in-process, with threads
for async operations.

* The GIO client: I would describe the client API as more low-level
and fine-grained, probably harder to use than KIOs Jobs. It provides
both synchronous and asynchronous operations. Transfers are modelled
as streams, quite similar to Java's IO streams. For instance you can
wrap a GBufferedInputStream around a GInputStream. Seeking is also
supported. It also contains some other stuff, like Volume and Drive
management - everything you basically need for file-management. And
nice OO design too. In my opinion it would qualify as *the* basic API
for desktop file-mangement, but of course it should be wrapped by a
nice Qt/C++ API in KDE style.

* File attributes: GFileInfo has some similarities with UDSEntries,
but the properties have names and namespaces rather than integer
codes. When querying a FileInfo or listing a directory you can narrow
the query to certain property names (columns if you see it as a
database) or namespaces, in order to get a leaner and quicker
response.

* Quality of protocol handlers: That question i can't really answer.
Everything i tried (FTP, SFTP, SMB, Bluetooth), worked pretty well,
but GVFS developers probably can tell you more. I read somewhere
that's it's also gonna be used for HTTP in an Webkit based browser,
but i'm not sure. I also don't know how the HTTP handler works - if
it's a single multithreaded instance, or not...

However the devil is in the detatils. I can't tell if GIO/GVFS can
really provide everything KDE needs. I tried to investigate with
KIO-Giobridge for the most common protocols and that worked. But HTTP,
POP3 might be hairy.

Cheers,
Norbert