[PATCH] Multi-Protocol IO-Slave
thiago at kde.org
Sun Jan 13 20:09:44 GMT 2008
Kevin Krammer wrote:
>> * Part of KIO sits in kded i think (but i'm not an expert on this) - i
>> wouldn't call that desktop independent.
>The slave scheduler/launcher. Used through DCOP in KDE3 and through
> D-Bus in KDE4 (AFAIK). Could have been implemented as a separate
> process and using an independent name if necessary.
That's klauncher. It's an independent program (not part of kded) whose
only purpose is to launch ioslaves and other applications.
I briefly considered changing the KIO QDataStream-based protocol to a
D-Bus based one during last Akademy. I quickly gave up when I realised it
would be far too much work. I did the initial work, though, which is
present in today's KIO::Connection abstraction layer.
It is entirely possible to switch that layer to a D-Bus-based one in the
In any case, I applaud norbert's work and persistence. He's been
advocating a common VFS layer for quite a few years already.
I do not think, however, that GIO is the answer. For one thing, we've just
released KDE 4.0.0 with KIO support. That means we'll support it for the
next 5 years or so. For another, I don't see KDE developers writing
GIO-based slaves any time soon. They will write KIO-based ones because
they are simpler to write.
Which brings me to two suggestions for future work:
1) a KDE/Qt-based implementation of the required parts of GIO, so that KDE
developers "feel at home" writing ioslaves.
2) the reverse bridge, so that GIO/GVFS-based applications can use
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel