Porting kio-slaves to GnomeVFS modules

[nf]

On Thu, 2004-12-23 at 02:50, Thiago Macieira wrote:
> nf wrote:
> >One way of doing that would be to write a C++ wrapper on top of the
> >Gnome-VFS-module API which acts like the KIO::SlaveBase class.
> 
> As I understand it, Gnome-VFS is basically a table of function pointers. 
> KIO::SlaveBase is just that, though more complex.
> 
> You'll need to reimplement the SlaveBase class in order to receive input 
> from the Gnome-VFS master. However, bear in mind that you must respect 
> the usual C++ Binary Compatibility guidelines when doing so.

I think we can't use them "as is". So binary compatibility won't be
possible. The main reason is that io-slaves are designed to run async
only. Therefore they provide single methods for "get", "put" or
"readDir" and push back data with callbacks.

GVFS modules on the other hand have a synchronous API, similar to
traditional IO functions (Async usage is optional - AFAIK they run as
threads inside the GnomeVFS daemon in that case).

That means you have to split the "put" and "get" methods of io-slaves to
separate "open", "read/write" and "close" methods. Same thing for
reading directories. But a nice wrapper to be able to write modules in
C++ could still make porting easier.

Perhaps it should be written in "glibmm" C++, just like the C++ GnomeVFS
client API, which already exists: 
 
http://www.gtkmm.org/gnomemm2/reference/html/namespaceGnome_1_1Vfs.html

> 
> >2) Dependencies to KConfig of certain slaves to store configuration
> >data. (smb for instance).
> 
> See #5.
> 
> >3) Dependencies to Password storage via DCOP. But that's easier to
> > solve, because SlaveBase has a well defined API for that purpose.
> 
> And ioslaves should be prepared to the case where no storage is available.
> 
> >5) Metadata
> 
> Metadata and slave configuration are merged into one inside KIOSlaves. You 
> have two kinds of informations, both provided by the I/O master (i.e., 
> ioslaves do not read config files!):
> 
> - explicit metadata
> information that was explicitly set as metadata by the calling application
> - implicit configuration
> information read from config file <slavename>rc, composed of a merging of 
> hostnames and domain names. For instance, UA identifications are stored 
> in kio_httprc in such a way.
> 
> In any event, that information is sent by the calling application to the 
> ioslave.
> 
> >6) "Q"-code inside io-slaves:
> >
> >Because QT is split into QTCore and QTGui in Qt4 a dependency
> >of those modules to QtCore shouldn't be a problem. The GPL license also,
> >because the ported slaves link to Qt and Gnome-VFS, and not the other
> > way round...
> >
> >Alternatively KWIG could be used to mimic the "Q" stuff...
> 
> The KIOSlaves were designed to be run as out-of-process processes. 
> Therefore, they do not link to the application code and GPL restrictions 
> don't apply (IANAL).
> 
> That said, we may have to revisit that discussion later as SELinux becomes 
> more important and rules restricting specific applications should apply 
> to their network accesses as well, not to ioslaves (or, worse, 
> "kdeinit").
> 

Thanks for your comments!

> 
> Have you thought about the suggestion people made of unifying the backend 
> files first (bookmarks, etc.)

I'm not trying to discourage anyone from doing that. But personally i
think the "Let's standardize backend file-formats first" approach takes
too long, is too "protective" from attitude, and will be hindering
innovation in the future. You will need a common VFS codebase anyway. So
why not start "early" with exploring how to get there.

Regards,

Norbert