--nextPart2657632.zD6WKWaR0t
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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.=20
KIO::SlaveBase is just that, though more complex.

You'll need to reimplement the SlaveBase class in order to receive input=20
from the Gnome-VFS master. However, bear in mind that you must respect=20
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=
=20
have two kinds of informations, both provided by the I/O master (i.e.,=20
ioslaves do not read config files!):

=2D explicit metadata
information that was explicitly set as metadata by the calling application
=2D implicit configuration
information read from config file <slavename>rc, composed of a merging of=20
hostnames and domain names. For instance, UA identifications are stored=20
in kio_httprc in such a way.

In any event, that information is sent by the calling application to the=20
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.=20
Therefore, they do not link to the application code and GPL restrictions=20
don't apply (IANAL).

That said, we may have to revisit that discussion later as SELinux becomes=
=20
more important and rules restricting specific applications should apply=20
to their network accesses as well, not to ioslaves (or, worse,=20
"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=20
files first (bookmarks, etc.), instead of going to all the trouble of=20
unifying code?

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

2. T=F3 cennan his weorc gearu, ymbe se circolwyrde, wear=F0 se c=E6gbord a=
nd se=20
leohtspeccabord, and =FEa m=FDs c=F3mon lator. On =FEone d=E6g, he hine res=
te.

--nextPart2657632.zD6WKWaR0t
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBByiRbM/XwBW70U1gRAiGZAJ47V9qM8IeG8xXosd1Oceb7dbsFcQCeMzMq
xREWcal7cTQloKiCZwS1eK4=
=w3XF
-----END PGP SIGNATURE-----

--nextPart2657632.zD6WKWaR0t--