Re: kio-gio bridge

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: kio-gio bridge
by Norbert on Sunday 20/Jan/2008, @04:20

> The "kio-giobridge" makes it possible for KDE programs to using GIO/GVFS. Of
> course in places where KDE already have native IOSlaves handling the protocoll,
> it does not make much sense for the users.

Well, the idea behind "kio-giobridge" is that it does make sense to switch off KDEs native IOslaves and to use the shared implementation instead. This is because GIO/GVFS works similar to UNIX mounts: You mount a certain ftp server or smb share and all applications/file-managers can use them without logging in again. The servers/shares stay mounted until you hit the unmount button. Therefore working with network file systems should feel a lot more coherent. You don't have to log in twice when working with KDE apps and Gtk/3rd party apps on the same shares and you don't have to pray that KIOs and GIOs protocol handlers are functionally equivalent.

Related Links

·   Articles on Developer
·   Also by Norbert
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: kio-gio bridge
by Allan Sandfeld on Tuesday 22/Jan/2008, @00:38

Except the implementation is not shared. It is just a crappy GNOME attempt to copy KDE. So let's stick to our own implementation instead of promoting second-rate copy-cat implementations.

[ Reply To This | View ]

Re: kio-gio bridge
by Vide on Tuesday 22/Jan/2008, @04:40

If there's this "mount like" features, it's definetely better than KIOslaves, at least from an architectural PoV. The fact that KIOslaves are KDE-only and so from the shell or whatever program not using kdelibs (even Qt ones!) you cannot use them directly, sucks so hard... don't get me wrong, if KDE ruled the world, KIOslaves would be the non plus ultra, but since biodiversity is something directly bind with FLOSS, than we have a problem.
The best Linux implementation should be using FUSE, but then we have a problem with other platforms. Don't know exactly how GFS is solving this, but if they can get a mounted point transparent to the system, then they have a winner.
(I mean, the clear example here is OSX, which has the best way to implement remote access)

[ Reply To This | View ]

Re: kio-gio bridge
by SadEagle on Tuesday 22/Jan/2008, @10:21

KIO slaves are no more KDE specific than GIO is gnome-specific --- so what's your point? Actually, you don't have to link to KDE libraries to use I/O slaves --- they are out of process, w/a dbus + socket protocol, so there is absolutely nothing preventing one from writing implementations of slaves or client libraries w/o using KDE libraries.

P.S. KIO does a lot more than VFS, too. And having two overlapping systems used for the same codebase is freaking insane.

[ Reply To This | View ]

Re: kio-gio bridge
by Norbert on Tuesday 22/Jan/2008, @13:26

> KIO slaves are no more KDE specific than GIO is gnome-specific --- so what's your point? Actually,
> you don't have to link to KDE libraries to use I/O slaves --- they are out of process, w/a dbus +
> socket protocol, so there is absolutely nothing preventing one from writing implementations of
> slaves or client libraries w/o using KDE libraries.

Well - in theory KIO could be implemented desktop independent, that's true. But in praxis rewriting the client and daemon/slave parts isn't easy. As GIO/GVFS already is desktop independent in the implementation, and also seems to have some advantages in design, why not go for it?

> P.S. KIO does a lot more than VFS, too. And having two overlapping systems used for the same
> codebase is freaking insane.

Why is it overlapping? Parts of the functionality in KIO (particularly network transparent file-management like smb, ftp, sftp, webdav) would be delegated to GIO/GVFS. That's just putting the KIO interface on top of a shared implementation.

[ Reply To This | View ]

Re: kio-gio bridge
by SadEagle on Tuesday 22/Jan/2008, @15:04

> Well - in theory KIO could be implemented desktop independent, that's true. > But in praxis rewriting the client and daemon/slave parts isn't easy. As > GIO/GVFS already is desktop independent in the implementation, and also seems >to have some advantages in design, why not go for it?

First of all, there is no reason to rewrite anything. Multiple implementations can talk on the same wire protocol. And GIO is "Desktop independent"? That's just nonsense, to put it politely. It's written exact way GNOME developers like to write things. And "why not" throw out something that works pretty well for a new toy, just because GNOME is being NIH again? Are you being freaking serious?

> Why is it overlapping? Parts of the functionality in KIO (particularly
> network transparent file-management like smb, ftp, sftp, webdav) would be
> delegated to GIO/GVFS. That's just putting the KIO interface on top of a
> shared implementation.

Because you would need the core KIO infrastructure for things like kio_http, kio_imap4, etc. And as someone who may have to fix things in kio_http, I sure as heck won't want to deal with a mismash of g* code in KIO core.

[ Reply To This | View ]

Re: kio-gio bridge
by Kevin Krammer on Tuesday 22/Jan/2008, @15:53

> First of all, there is no reason to rewrite anything.

I think he didn't mean to use the word "rewrite", i.e. replacing an existing implementation with a new one, I am quite certain he meant "from ground up", i.e. starting to implement a second stack starting at the wire level.

> And GIO is "Desktop independent"?

Again I think this is just unfortunate wording. In this context it more likely means "not linking against any GUI library", e.g. an implementation just linking with QtCore would also be "Desktop independent".

[ Reply To This | View ]

Re: kio-gio bridge
by Norbert on Tuesday 22/Jan/2008, @17:27

>> First of all, there is no reason to rewrite anything.
>
> I think he didn't mean to use the word "rewrite", i.e. replacing an existing
> implementation with a new one, I am quite certain he meant "from ground up",
> i.e. starting to implement a second stack starting at the wire level.

Yes, thats right.

> And GIO is "Desktop independent"?
>
> Again I think this is just unfortunate wording. In this context it more likely
> means "not linking against any GUI library", e.g. an implementation just linking
> with QtCore would also be "Desktop independent".

Yes, exactly. It's not possible use KIO and it's protocol handlers without installing and running some KDE specific stuff at the moment. Perhaps that's all more on the edges of KIO, but it makes it less attractive for using it cross desktop.

[ Reply To This | View ]

Re: kio-gio bridge
by Norbert on Tuesday 22/Jan/2008, @19:03

> And "why not" throw out something that works pretty well for a new toy, just because GNOME is being NIH again?

I don't think it's fair to call it a "toy". They have implemented something that from design comes very close to what has been discussed since many years ("D-VFS", "Common-VFS", "Shared-VFS",...). Unfortunately it was not there before KDE4 development started.

> Because you would need the core KIO infrastructure for things like kio_http,
> kio_imap4, etc.

Sure, but they are kind of in a different domain (used internally by certain KDE applications).

I agree that what i'm proposing looks a bit weird, it's just that i don't know of a better pragmatic solution.

[ Reply To This | View ]

Re: kio-gio bridge
by Richard Moore on Wednesday 23/Jan/2008, @02:29

> Why is it overlapping? Parts of the functionality in KIO (particularly
> network transparent file-management like smb, ftp, sftp, webdav) would be
> delegated to GIO/GVFS. That's just putting the KIO interface on top of a
> shared implementation.

You seem to be saying instead of maintaining a single well tested code base, we'd now need to maintain two of them. One of which is unproven, and only covers part of the problem space. I don't see this as a winning argument.

[ Reply To This | View ]

Re: kio-gio bridge
by Norbert on Wednesday 23/Jan/2008, @04:37

>> That's just putting the KIO interface on top of a
>> shared implementation.
>
> You seem to be saying instead of maintaining a single well tested code base,
> we'd now need to maintain two of them. One of which is unproven, and only covers
> part of the problem space. I don't see this as a winning argument.

First, i would always rate usability higher than maintainability. But i'm pretty sure that moving towards a shared implementation, even if it's only for the VFS parts of KIO, will in the long run reduce maintenance "cost" as well.

However, as things are evolutionary, lets just try with an optional plugin and see if users like it. It's far too early to discuss maintenance cost or whether GVFS should really replace certain parts of KIO by default.

[ Reply To This | View ]

Re: kio-gio bridge
by SadEagle on Wednesday 23/Jan/2008, @07:57

Software development is 90% maintenance.

[ Reply To This | View ]

Re: kio-gio bridge
by Vide on Wednesday 23/Jan/2008, @06:37

And what about shell access? Legacy apps? Well, the fact is that KDE should use FUSE as its KIO backend, and be the "weight behind" to get FUSE ported to platforms where it's not present or not fully implemented. This way if there's KIO, GIO or whatever else *IO, it's not that relevant, everyone could be happy and work better (I would do, at least :-)

I know this is armchair programming but that's the direction I would like to see for the *nix desktop experience

[ Reply To This | View ]

Re: kio-gio bridge
by Jel on Tuesday 22/Jan/2008, @05:29

Seems to me that the only proper way to implement network filesystems is in the actual filesystem layer, underneath both gnome *and* kde.

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"Default settings are easy to manage." -- Aaron Seigo
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.