Kill KIO (was: Repositioning the KDE brand)
phreedom.stdin at gmail.com
Fri Jul 10 15:36:35 BST 2009
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.
> 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
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...
* 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:
* non-trivial slaves
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
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-
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.
More information about the kde-core-devel