Porting kio-slaves to GnomeVFS modules

[Thiago Macieira]

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.

>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").

>Just some thoughts, really don't know if that would make sense...
>
>Norbert

Have you thought about the suggestion people made of unifying the backend 
files first (bookmarks, etc.), instead of going to all the trouble of 
unifying code?

-- 
  Thiago Macieira  -  thiago (AT) macieira (DOT) info
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se 
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041222/8fcb1d18/attachment.sig>