DBUS on Windows

Since Christian Ehrlicher expressed his unhappiness with our (KDAB's) efforts in the area of DBUS on Windows in this blog post, I thought I'd clarify some things. The work that we announced in <a href=http://lists.freedesktop.org/archives/dbus/2009-April/011207.html

this post to the dbus mailing list is not a "new project" that we started in disregard of the windbus efforts of the KDE/Windows team. In fact, it includes that work and builds on top of it. As the announcement mail clearly states, what we've done is take the windbus branch in sourceforge svn and carefully rebase it on top of the upstream git repository, thereby transferring all the changes that went into windbus over the years into a git branch relative to upstream git master. While doing so we cleaned up many line ending and whitespace bits to make the branch as clean as we can, separating some commits into easier to review chunks, merging some others that semantically belong together, separating out merge and reverse merge commits, etc. All this in order for windbus to be merged into upstream dbus, which was the original plan of windbus all along. This took a lot of very careful and partially very boring work. Marc, Frank and Sebastian needed several weeks to walk the entire svn history of windbus manually, looking at every single commit, in order to ensure that nothing is lost in the process. They also looked at various other patches that were floating around the mailing lists and blogs from others who had also worked on DBUS on Windows and other platforms. These patches were also integrated into git branches, again with the sole intention of merging them upstream into dbus master. Additionally the team implemented (and partially merged from other patches) support for cross compilation to Windows, which, along with the windbus provided cmake build system, provides an alternative way to build dbus for Windows binaries.

In parallel to this work, again, entirely based on windbus and other long unmerged (into upstream dbus) patches and with the sole intention of finally getting that work upstream, we have started implementing an additional transport, which extends the currently used TCP transport in two ways. It can work on a non well-known port, thus enabling multiple dbus servers to run on the same box (some of this came in from patches as well) and it adds a security mechanism that effectively ensures that only the owner of a token file which contains the port number for that user and a secret token can actually talk to the server on each port. This is totally orthogonal to the windbus work and an extension that we think is necessary and useful. We are currently extending the spec document to describe this, in order for it to be accepted upstream as well. I'd like to add that all of this work happens in coordination with upstream dbus, Thiago, in particular, and with the knowledge of the dbus maintainers, taking their input into account in order to ensure full upstream acceptance.

So to summarize, this work is neither a fork of windbus, nor of upstream dbus, it aims to finally re-unite them. We are trying to make good on our promise to provide a reliable and fast DBUS on Windows, and the testing so far indicates that it's working very nicely. We've integrated it as a target into emerge, such that it is testable by the KDE/Windows hackers and users as early as possible. Any feedback is of course appreciated.

As to the reasons why we have not tackled this before, they are twofold: firstly we (Jaroslaw, at that time) had managed to get the most pressing issues in dbus on Windows sorted to the point where it was basically usable, such that we chose to focus on other, more immediately urgent issues, and secondly we simply did not feel that without the time to solve the problem properly, do it cleanly and in coordination with upstream dbus, we would stand a very good chance of getting it merged, thus falling short of a real solution, so we deferred it. Now we are doing it, since it needs doing.

Christian, I hope that clarifies things a bit, at least with respect to our current dbus work. I'll address your other points in a separate post.