[PATCH] Multi-Protocol IO-Slave
kevin.krammer at gmx.at
Sun Jan 13 16:32:01 GMT 2008
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
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
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- 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