Porting kio-slaves to GnomeVFS modules

[nf]

Hi!

On Tue, 2004-12-28 at 23:51, Jason Keirstead wrote:
> On December 28, 2004 11:59 am, nf2 wrote:
> > I have started writing a plain C++ layer for writing portable VFS
> > modules (to be be used in different VFS environmens like KIO, GnomeVfs,...)
> >
> > At the moment it's just the beginning of an interface proposal. But i am
> > sure with your help it could become something useful... :-)
> 
> It looks way too C-ish to me.... open(), seek(), and close() calls 

The fact is that all synchronous IO functions work like that. In any
language. Gnome-VFS modules have a synchronous "in-process" interface,
which is not so bad from design. Like in my KIO->Gvfs bridge (the
"gvfs-kio" slave) it's easy to plug them into an async system like KIO.

> with char* 
> buffers? Why would we use such dated stuff when we have QT. Give me my 
> KIO::Job into a nice safe QByteArrays back, thanks :) The only way I could 
> see this type of thing being used in KDE is if the existing KIO layer were 
> totally re-written to use this underneath. But that would be a lot of work 
> for not much benefit.

Please look at the illustration in the bottom of this page to understand
how i would like to plug things together for a Common-VFS:

http://www.scheinwelt.at/~norbertf/common-vfs/COMMON-VFS-BENEFITS.html

> 
> Also - I don't know how you plan on making VfsUri UTF safe without using an 
> external lib - and then you have the thing again where linking against said 
> lib would just be duplicating functionality already present in QT.

My idea was that VfsURI is just a wrapper around the URI
classes/functions the underlying VFS provides. Like KURL or GnomeVFSURI.
http://developer.gnome.org/doc/API/2.0/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-uri.html

> 
> This is the biggest problem with these cross-library proposals - you never 
> want to depend on QT, so always end up using other libraries that basically 
> duplicate portions of QT's functionality (hello glib:).  But in KDE we 
> already use and love  QT, so why would we want to link againt other third 
> party libraries that offer pieces of functionality already in QT, that are 
> even often (arguably) inferior?

Well - sometimes they are better and sometimes they are inferior. Glib
main loop seems to be excellent from design for instance. A lot better 
than Qt main loop.

Generally i don't have a problem with having a Qt-Core dependency for
VFS modules. And maybe the C++ porting layer should be based on Qt if
that makes you happy. The real question is how other dependencies could
be minimized (like KDE dependencies which come with the class KURL used
in kio-modules (slaves) at the moment). Because IMHO a VFS library needs
to be as lean as possible, because it should really be used by everyone
- outside KDE and GNOME as well. 

Regards,

Norbert