moving file descriptor passing into a header

[Luiz Augusto von Dentz]

Hi.

On Wed, Apr 14, 2010 at 11:15 AM, Fridrich Strba
<fridrich.strba at bluewin.ch> wrote:
> Hello, good people,
>
> On Wed, 2010-04-14 at 01:19 +0200, Marcus Brinkmann wrote:
>> Actually DBus on Windows is used in production in the KDE port to Windows, for
>> example in the Gpg4Win package that contains the Kleopatra certificate
>> manager, and Kontact-for-Windows.  The current port only supports the session
>> bus, not the system bus, but this is only because currently nobody requires a
>> Windows system bus.
>
> One can argue whether dbus is designed for Unix, nevertheless, it
> becomes so omnipresent that you cannot port many FOSS applications if
> you don't have it. There are cases where you can avoid using dbus by
> providing another IPC mechanism for windows (like it could be done with
> libunique), but in other cases you just don't have choice.
>
> We have a little bit patched version of dbus-1 and dbus-1-glib in our
> openSUSE Build Service repositories of windows packages
> (http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Factory/noarch/ and
> http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_Factory/noarch/)
> because nowadays evolution-data-server and evolution depend on it
> inconditionally. So, considering portability issues would make the
> Windows porting a bit less PITA for those of us that care :)

Every time I see such discussion on list I asked myself if having such
ports are really a good idea, it seems clear to me that it only
fragments the community and obviously makes the code a lot more
complex. Not to mention that in Windows it is basically just another
IPC, session bus only, no system integration whatsoever, so instead of
porting the application itself to Windows we need to port the IPC
mechanism, priority inversion?

Now back to the point, fd passing is a unix only feature as Lennart
mentioned, it is has to be negotiated and has been in the repository
for quite long time, so why is such a resistance?

There are a lot of nice things we can do with fd passing on linux, and
at least BlueZ, ofono, connman and PulseAudio already uses it or has
work ongoing to integrate it, still no sign of stable release.

We are already using code such as this:

	dbus_message_append_args(msg, DBUS_TYPE_UNIX_FD, &fd,
					DBUS_TYPE_INVALID);

So if I understand it correctly this won't work anymore and we will
have to deal with it separately, by doing:

if DBUS_TYPE_UNIX_FD
	dbus_message_append_args(msg, DBUS_TYPE_UNIX_FD, &fd,
					DBUS_TYPE_INVALID);
else
        dbus_message_append_unix_file_descriptor(msg, fd);

Is that right?

-- 
Luiz Augusto von Dentz
Computer Engineer