[PATCH] Multi-Protocol IO-Slave

[Kevin Krammer]

On Sunday 13 January 2008, nf2 wrote:
> Kevin Krammer wrote:
> > On Sunday 13 January 2008, nf2 wrote:
> >> Jeff Mitchell wrote:
> >>> Personally, I'm all for a single network transparency library (or a
> >>> single authentication caching library, which would serve the purpose). 
> >>> I do think it's utterly stupid that the GNOMEs couldn't contribute to
> >>> KIO, which already has a bazillion working, useful KIOslaves, unless
> >>> they felt (as they seem to) that GIO/GVFS is better by design.  Still,
> >>> it does reek a bit of "we just can't allow ourselves to use anything
> >>> with a K in it" syndrome.
> >>
> >> The problem is that KIO always had desktop/GUI-toolkit dependencies and
> >> KDE developers never cared to remove them - so it's your fault, guys.
> >
> > As far as I know there aren't any.
> > If you are referring to the issue that there hasn't been any formal
> > specification of the KIO master/slave protocol I am not aware of any such
> > thing regarding GIO/GFVS either.
>
> Of course there are/were lots of toolkit and KDE dependencies:

In KDE's implementation of the system, of course.

> * AFAIK a GUI-less Qt-Core didn't exist until Qt4. It hasn't been
> attractive for anyone outside KDE having to install a full blown GUI
> toolkit library just to use KIO. Of course with Qt4 the situation might
> be different.

There has been no dependency on Qt in the KIO architecture, obviously a Qt 
based implementation does.

> * The KIO client always had - and still has - UI stuff inside.

KDE's KIO client.
Since basically all KDE applications are GUI applications, this hasn't been a 
problem. I guess it could have been abstracted out if necessary though, even 
in KDE's implementation.

> * 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.

> I didn't really refer to standardizing the internal KIO master/slave
> protocol. I don't think that would have been necessary as long as the
> rest of the system (client library/protocol handlers) were desktop
> independent in terms of dependencies. Just like everyone uses libsmbclient.

A specification is always necessary for real independence, it basically is the 
only means of making it really hard for a single entity to control 
interoperability.

If we have had official protocol specifications for DCOP and KIO in the first 
place, people might not have started to falsy claim they had any KDE 
dependencies.
"Might" because even technologies which had no Qt dependencies at all, e.g. 
aRts, have been avoided because somebody created the false claim that it  
had.

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/20080113/7939ec98/attachment.sig>