KIO->GnomeVFS bridge started (looking for a Common-VFS)

[nf]

On Tue, 2004-12-21 at 14:49 -0400, Jason Keirstead wrote:
> This also leads to a big downfall of Gnome / Gtk IMO - because everything is 
> so modular, you end up with very inconsistent apps. 
> 
> Even though there are things like the Gnome HIG, Gnome / Gtk apps are far less 
> consistant in their UI than KDE ones. The IO slave stuff is a perfect 
> example. KIO slaves have GUi code in them for one reason - so that, in every 
> possible usage, you get the same file and progress dialogs.
> 
> This is not true in Gnome - not by a longshot. Depending on the app, you could 
> get any one of 3 or 4 GTK file selection dialogs, and any one of two or three 
> progress dialogs (that is, if the GVFS slaves are even available in the Gnome 
> application / the application even shows progress dialogs. Frequently they 
> are not / it does not.)
> 
> KDE always strives for integration, and this is what I love about it. If I 
> have to suffer some modularity of the libraries in order for my apps to be 
> more consistent and well integrated, so be it - that is a sacrifice I will 
> make.

That's talk from the marketing department ;-). I'm just interested in
common infrastructure issues. And there should be no GUI dependencies in
cross desktop libraries - that's for sure.

> 
> > I think using KIOSlave code inside Gnome-VFS is definitely a good idea.
> > But i would not use them as they are, but rather write a C++ porting
> > layer on top of the Gnome-VFS modules concept which almost acts like the
> > SlaveBase class, but without Qt stuff inside. Porting them should be
> > possible, because the Qt bindings of io-slaves are not very strong.
> 
> Why would you want take the existing KDE code, write a porting layer, and move 
> it to GVFS? (and then, I assume, port KIO to use GVFS?) 

First, because a Common-VFS should be lean and not have too many
dependencies. Dependencies inside io-slave code have to be redirected to
libraries which can also serve as common infrastructure.

Secondly, because Gnome-VFS has a bit different concept for its modules.
Unlike KIO the gvfs-modules can be used "in-process" for synchronous
calls and in an async way. AFAIK they run as threads in the
Gnome-VFS-daemon when you decide to use the async functions. When using
them asynchronously, CORBA is used as IPC protocol. Therefore there
would be no need for another IPC protocol (like the KIO IPC protocol).

For the KIO->Gvfs bridge experiment i use the synchronous calls from the
gvfs-kio-slave for instance - therefore there should be no performance
loss compared with original KIO-slaves.

> All you are doing is 
> introducing additional code paths and potential bugs in the slaves.

True. But if the porting layer is good, it shouldn't be too hard to
"sync" bug-fixes. Io-slaves are not that huge libraries.

> 
> If you re-implement the KIO IPC mechanism for GVFS, you have no new code 
> paths, the slaves are the exact same, and you can debug the IPC independently 
> of the slaves. Also, any new KIO slaves will instantly work without any 
> porting or re-compiling. Less risk, more reward.
> 

That would mean making KIO the Common-VFS. An option that should also be
evaluated. I have flipped the coin and chosen to experiment with
Gnome-VFS as the "Common-VFS". But maybe someone else would like to try
it the other way. :-)

Norbert