KIO-GIOBridge and KIOs portability

[nf2]

On Fri, Jul 17, 2009 at 4:51 AM, Evgeny
Egorochkin<phreedom.stdin at gmail.com> wrote:
>
> You can replace GIO with KIO, but not vice versa.
>

There is some truth in that.

KIO is not a very strict API. It's ingenious and elegant that it can
be used for so many different things, but when porting it to a
different platform, that flexibility becomes a stumbling block. That's
kind of the reason for the "mixed feelings" i got about KIO.

KIOs universal "soft" API approach has the consequence that KIO can
only be replaced by an exact KIO clone (If one wants to fully replace
it).

One example is the metadata methods in KIO::Job. Those methods are
inherited by all jobs, and it's very hard to tell where and how they
ought to be used. There is no clear API contract, you need to know how
the ioslave works in order to use it. Serving all the expected KIO
behavior with a different engine is very hard.

>> My initial statement was not accurate of course. It was not about KIO
>> in general as a technology of async IO helpers or as an API. Just the
>> VFS part inside it (with VFS i mean the items that usually show up
>> inside filemanagers and file-choosers).
>
> An artifical distinction for the most part as explained above with a proposed
> solution for people who want to stick to this distinction no matter what.

I don't think it's that artificial. It's importand to pin down the
problem. For instance the stricter GIO API would be sufficient to
serve Dolphin, file-choosers and most applications - but it's
definitely not sufficient to serve Konqueror with full featured HTTP.

As I described before, KIO doesn't make that distinction. But in order
to understand which technologies have to be shared between all
applications and DEs (platform technologies) a bit of distinction is
important. I think it's about shared resources, for instance if you
mount a CDROM, the kernel makes it available to all applications. GVFS
has extended this "mount-metaphor" to network-servers.

I think it's also important to make this differenciation in order to
find out how kdelibs could become more modularized and portable. I'm
glad that someone who is developing a KDE application spoke up in the
previous thread. I always had a bad feeling about the way
Desktop-Entvironments lock in applications. That's why i'm interested
in file-mangement, because it's probably the most important technology
that applications inherit from Desktop Environments.

I believe what KIO needs, is moving towards a turnout or plug-in model
right behind the API. It should be possible to register an in-process
module which handles a set of protocols. On other OSs it might be a
kind of light-weight system, which runs a limited set of io-slaves as
threads, thus not requiring the KDE runtime and D-Bus.

Secondly, abstracting the model behind filemanagers and file-choosers
in a central API would be cool (Drives, mounts, places-bookmarks). For
instance on Windows, bookmarks could be switched off and a Solid
dependency for listing drives might not be necessary.

>
> Suitable for what? Apparently nothing had been done to make it useful for KDE.
> Otherwise a working GIO-KIO bridge with password storage and UI(file transfer
> status notifications) integration would be already available in playground
> since it appears that somebody wants to make it happen...
>

Well - yes - KIO-GIOBridge seems to be still working. I fixed a little
compilation bug yesterday. Now i'm playing with enabling the GVFS
"archive:" protocol (which mounts tar.gz or zip archives, even when
they are residing on GVFS nework mounts).

The problem is that GVFS escapes the original location of the archive
in the host part of the URI:

archive://file%253A%252F%252F%252Ftmp%252Fsomething.tar.gz/

The problem is that the escape sequences are somehow lost on the way
through KIO and Dolphin:

This is what appears in the Dolphin location bar:

archive://file:///tmp/something.tar.gz/

and this when it hits the kio-gioslave again:

archive://file///tmp/something.tar.gz/

I suspect KUrl/QUrl are removing the escape sequences...

Another problem is that the unmount item is not appearing in the
context menu of the mounts i'm listing in my own implemantation of
"remote://" anymore. But i'd favour listing them in the places panel
along with "real" mounts anyway.

Cheers,
Norbert