Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)

[Ryan Lortie <desrt desrt ca>]

On Thu, 2009-10-15 at 12:38 -0400, David Zeuthen wrote:
> Yeah, I think we need to support this from the get-go. 
> 
> Anyway, at the end of the day, UNIX fds are just integers so if you
> require that users (such as GDBus itself and apps using GDBus) keep the
> fds alive until the method/signal has been sent/received you should be
> able to treat them as such. Anyway, it's probably more complicated than
> this.

I talked to Lennart on IRC and the 'h' type, as serialised, isn't a file
descriptor so much as it is an index into a table of file descriptors
that are stored separately (in a separate part of the DBusMessage).

Keeping this in mind, we could support this by doing the same thing with
GDBus -- support 'file descriptor array offset' as a special type of
integer in GVariant (much like 'o'bject path is a special type of
string) and have a GDBus call for send_with_file_descriptors() or such.

Lennart mentioned that he thinks that it's a bad idea that the
dbus_message_marshal stuff was ever added to libdbus, and that the
fd-passing stuff in libdbus will break if you try to use those
functions.  If we ever want to make a more efficient GVariant-to-DBus
conversion process we'll have to turn it off for the case where fd's are
present -- that's another reason for having a separate call, maybe.

I don't think we would want to have any more 'deeply integrated' support
than that, for a lot of reasons: Lennart mentioned that this only really
works on Linux (and of course, only works if you connect to the bus
using Unix sockets).  There's also the concern of what it would mean to
serialise a GVariant that contains an fd (to dconf, to the registry, to
text format, to XML, or to anything else).

Cheers