Common VFS: GKIO experiment

nf nf2 at
Thu Dec 9 22:57:26 EET 2004

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: 

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


More information about the xdg mailing list