Kill KIO (was: Repositioning the KDE brand)

Kevin Krammer kevin.krammer at gmx.at
Fri Jul 10 17:01:34 BST 2009


On Friday, 2009-07-10, 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!

Both this and the subject are rather poor ways of trying to get a useful 
discussion going, which makes the whole posting look more like a flamebait 
than anything else.

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

It is unfortunate that other software producing communities have difficulties 
using D-Bus and local sockets.
Unfortunately this is the same technology any other comparable solution uses, 
e.g. GVFS, so that won't help them either.

Speaking of GVSF it might be possible to introduce a Qt (or even KDE) based 
client library for GVFS, which could be used by applications along side KIO 
and which could be used to implement GVFS mount daemons using KDE 
technologies.

There are just a lot of use cases where KIO is dead easy to use and where the 
benefits of GVFS (e.g. limiting number of connections per remote side) don't 
matter that much.
However, there could still be use cases where using the explicit mount style 
system would be benefitial.

It didn't help that the other thread mentioned GObject a lot, which lead to 
mislead assumtions that GVFS would imply introducting such dependencies.
GVFS is, just like KIO, a service based approach of handling multiprotocol 
I/O, thus allowing any technology stack being used on both sides of the 
communication channels.

The application side for the KDE stack would therefore only consists of 
already used components. Whether there is the need to implement certain 
protocol handlers using our stack or whether those provided by others are 
sufficient would most likely have to be evaluated on a case by case basis.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090710/08abe598/attachment.sig>


More information about the kde-core-devel mailing list