[announce] dbus4win

[Havoc Pennington]

Hi,

On Tue, Apr 21, 2009 at 12:33 PM, Thiago Macieira <thiago at kde.org> wrote:
> Trying to map to Windows concepts will not work in all cases. I do agree with
> Havoc that we shouldn't use Unix emulation layers, but also going full Windows
> will be more trouble than it's worth. It would also make code maintenance a
> lot more difficult (more than it will be) because of the differing code paths.

To be clear, I'm not saying we can't have a TCP transport on Windows,
or a "TCP-socket-discovered-via-files" transport. Just don't think
there's any reason it has to be kind of wedged into the unix sockets
API or transport address in some kludgy way.

A TCP transport with Windows-specific port discovery should pretty
much share all the unix code; we already split dbus-transport-socket.c
(which is all the hard stuff) from dbus-transport-unix.c (which is a
tiny file) for that reason. The idea should be to use
dbus-transport-socket but not dbus-transport-unix (or any of the
functions with unix in the name, or from dbus-sysdeps-unix).

I'm pretty sure all the changes I've ever requested for the windbus
patch should have been a week or two of work, at most... esp. because
I did some of the hard bits like the unix fd vs. socket split, and
DBusCredentials abstraction. If I thought we were talking 3 months of
work I would have relented and said "OK fine we can put in the hacks"
but I don't think we should put in hacks to save 1-2 weeks of work, if
nobody has 1-2 weeks, nobody is going to maintain the windows port
anyway.

Anyway if named pipes are sucky, I think we should have a transport
like win-tcp (or whatever it should be called) that simply adds a way
to discover a TCP port (and host?) to connect to ... it could be via a
file (as long as the file is per-session on Windows - this has been an
open question). Another way that I think is common for Windows
singleton apps is to open a hidden window, and search for it by window
class, then send messages to it; that is not a lot of code to do.
Another way could be a COM singleton object, which I'm guessing would
be per-session by default. With the window or COM, you'd use messages
or COM calls to get the TCP info, then connect to the socket and hand
off to the cross-platform socket code. The window or the COM approach
might solve per-session in a way that the file doesn't, though,
putting the file in the right directory might fix per-session also, I
don't know enough about windows to say. I would like someone who does
know about windows to be able to say, however ;-)

Then the next question after that is probably how does the
authentication work on Windows.

One guideline is that if we can't document whatever we do on Windows
in dbus-specification.xml in a way that seems sensible and not
embarrassing, it's probably too hacky. I'd definitely recommend
documenting the Windows transport and auth in the spec before writing
a ton of code.

Havoc