Kill KIO (was: Repositioning the KDE brand)

[Evgeny Egorochkin]

On Friday 10 July 2009 16:12:05 nf2 wrote:
> On Thu, Jul 9, 2009 at 12:05 PM, Evgeny
>
> Egorochkin<phreedom.stdin at gmail.com> wrote:
> > So please be specific.
>
> Ok...
>
> I love KIO, but - please, please, please - throw it away!
>
> It's a "proprietary" system just for a minority of applications. 

It's for applications that care to link to it. The question is how hard it is 
to link with and use KIO?

> It's an obstackle for getting third party applications like openoffice.org,
> mozilla or Qt-only to use full fledged network transparent
> file-management.

But these developers need to link to a some lib anyway for this to happen. 
FUSE itself doesn't automount random stuff. @#$% POSIX doesn't allow URLs in 
regular system calls (that's where the biggest problem lies actually), while 
still allows nontrivial stuff like symlinks. On top of it you must manage 
passwords, proxies and jobs.

> It's an obstackle for running KDE applications on
> Gnome or Gnome applications on KDE.

Lack of a common interface is an obstacle, not KIO itself.

> It's not that exciting from design and capabilites anymore (compared to 
other options). It's a dead dog.

Emotions and "rubbing it in" have already done everything they could. To 
convince people you need an detailed review so that your proposal can be 
investigated on merit. As you can remember attempts at GObject<->QMetaObject 
interop, gnome stuff wasn't as nice as it was hyped, because people were 
comparing KDE reality and GNOME marketing(and maybe future).

I don't pretend to have in-depth knowledge of both KIO and GIO so these are 
pulled out^H^H^H^H^H just my observations...

AFAIK:
* KIO has a very nice Job support
* it supports much more than fetching http pages: media,pop3, bluetooth and 
such kioslaves come to mind

The consequences of using a KIO->GIO bridge:
* We get to share 4 or so protocols such as http, ftp and smb.
* Instead of these KIOslaves we get to maintain a rather complex patchwork to 
handle the brige itself, network preferences and passwords

In fact these protocols are either trivial to implement or are implemented 
using a lib we don't maintain, so KIOSlave is just a wrapper, probably much 
simpler one than KIO->GIO

If we drop KIO and go with GIO, we're going to be stuck with:
* Jobs
* non-trivial slaves
* GObject

So it seems we get lots of hassle with no real benefit. 

However there's another option: drift towards a standard lib that's indeed 
COMMON to the two desktops, port advantageous features/arch approaches(if they 
exist) to KIO. EG at this moment KIO depends on kdelibs which is bad from 
cross-desktop POV although in reality only a couple of header files seem to be 
relevant.

Removing kdelibs dep, making an option to run outside of kded, making 
interfaces friendly to GObject wrapping, there are lots of things we can do. 
Also talking to gnome devs about enhancing "GIOSlave" or whatever it is called 
API to satisfy our needs, while keeping daemon implementations desktop-
specific.

It's quite possible that we can achieve quite some code reuse and portability, 
enhance both KIO and GIO and keep our BIC promises. But for this to happen 
somebody must take time to analyze what/if/how it is to be done, and of course 
do it if it ends up being feasible...

If you're up to it, you're welcome ;)

> Sorry for repeating this - or a similar statement - once a year. I
> really don't want to damage KDE. Just the opposite.


-- Evgeny