[PATCH] Multi-Protocol IO-Slave

[Kevin Krammer]

On Sunday 13 January 2008, Jeff Mitchell wrote:
> On Sunday 13 January 2008, nf2 wrote:
> > Apart from the desktop/toolkit independence (just GLib and D-Bus) and
> > that one VFS is always better than two (For 3rd party applications the
> > situation was like the donkey stuck between two haystacks, they avoided
> > to choose KIO or Gnome-VFS - which sucks) - yes - i think GIO/GVFS is
> > better than KIO and you will want that stuff.
>
> Some of the things you mentioned sound nice, but apart from the requiring
> glib thing, I have a few questions:
>
> First, on http://live.gnome.org/GioToDo it says, "There is some parts of
> gio that should really be in Gtk+ that apps might need. Long term this
> should go into Gtk+, but for now we might want to put these in a separate
> desktop library so that apps can start using gio easily before the next
> Gtk+ release."
>
> While these classes could be worked around by having KDE implementations, I
> find it a bit troubling that they want to move some parts of GIO into GTK.
> Then your dependencies go from glib/dbus to glib/dbus/gtk, at least by
> default.  What other parts of GIO/GVFS might they at some point decide
> really belong in GNOME-specific libraries?

This is misunderstanding caused by the unfortunate phrasing (speaking of 
dependencies) used above.
Norbert wants to point out that the current implementation has only very few 
dependencies, especially no uncommon ones.

As with any other design where processes communicate through means like 
socket, an implementation dependency is not a hard requirement for the whole 
system.
It is obviously more convenient and probably faster in terms 
of "time-to-market" to use an already existing implementation, but if 
technical or legal (e.g. licencing) or any other issues make this hard or 
impossible, it can be solved by providing your own client and/or server stack 
while still supporting the system.

As an example take D-Bus: the various C and C++ based bindings are using the 
D-Bus base library libdbus so they do not have to care about protocol issues, 
however the binding developers of managed environments (Java and Mono) have 
opted to keep the native/non-managed parts minimal (basically just Unix 
socket IO) and implement the protocol stack within their own environments.

Since the current usage pattern we are discussion here is an additional IO 
slave, thus its dependencies staying within its process, it would be foolish 
to not use the already exisiting client implementation.

Using it directly in kdelibs, either as an implementation variant in KIO or as 
a new API, could probably be handled with a frontend/backend architecture 
like Solid or Phonon, leaving the possibilty to switch to an implementation 
without external dependencies if necessary (e.g. external implementation 
requiring GTK+)

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/88b22d7d/attachment.sig>