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