Re: Common VFS: GKIO experiment

[nf <nf2 scheinwelt at>]

On Wed, 2004-12-08 at 11:33, Waldo Bastian wrote:
> [Cross-posted this time, with some changes to the dispatch part]
> On Wednesday 08 December 2004 01:12, nf wrote:
> > In order to find a way out of this situation, i would like to start an
> > experiment: To write a (KDE/C++) wrapper to Gnome-VFS which looks and
> > acts like the KIO-API - "GKIO". Then write a number of test-cases, which
> > test the GKIO-API for KIO requirements and compatibility. Once this
> > tests work, i want to try plugging GKIO into kde-core libs (instead of
> > original KIO code).
> 
> The API you are looking for is the io-slave API. In particular 
> kdelibs/kio/kio/slaveinterface.h and kdelibs/kio/kio/slavebase.h
> 
> The easiest is to start by making a single (out of process) ioslave, there are 
> plenty of io-slaves available as example, but the file ioslave 
> (kdelibs/kioslave/file) is probably relatively close to what you need.
> 
> In general io-slaves don't use the Qt event loop at all, so you don't need to 
> merge it either. If you need the glib event loop you may need to merge it 
> with SlaveBase::dispatchLoop() which handles the communication between 
> application and io-slave. Typically the slave is idle when it hangs around in 
> dispatchLoop(), waiting to get a new command from the application, so I don't 
> think you would have much glib events to process there.
> 
> If you need to do things in-process (but I can't see why actually) you can 
> have a look at the data io-slave, kdelibs/kio/kio/dataslave.cpp
> 

Thanks! Although my approach was a bit different, this seems to be
relatively easy. I try to understand:

* Write a "generic" Gnome-VFS io-slave, which gets "reused" for (almost)
all protocols. That would mean all .protocol files map to the same
gkio-slave.so library. This is possible, because the constructor
SlaveBase() is told, which protocol it has to handle. 

* The kioslave event loop has to be plugged into the glib eventloop. AFAIK Gnome makes heavy use 
of all kind of IPC internally (CORBA), therefore this is essential. The problem might be that 
SlaveBase::dispatchLoop() is not declared "virtual", thus it will be harder to add the kioslave 
fds to the glib main loop. Some patching of the kdelibs will be necessary. 

* Because it's async to KDE, the gkio-slave can use the Gnome-VFS synchronous functions 
- like the xfer functions described here:
http://developer.gnome.org/doc/API/2.0/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-xfer.html

* 

* 

I would call this approach "conservative", because it makes it hard to hand additional Gnome-VFS 
functionality to KDE in the future (streams?), because we are locked into the io-slave concept. 
My initial idea was to hack Gnome-VFS into the KIO front-end API by calling into Gnome-VFS directly
from the KIO::xxxx() and KIO::NetAccess::xxxx() functions.