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 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.

> Read More... | Digg This!

Haven't blogged for a while, so here's some of the changes that have happened in Kubuntu recently.

I finally found some time for the KDE port of system-config-printer, still far from feature parity with the Gnome version and needs plenty of tidying up but should be usable.

mornfall got back to hacking on Adept 3 featuring super fast xapian search.

In other packaging news the Dist Upgrade tool got a pyQt 4 port.

And gdebi, the .deb installer, got a pyKDE 4 port.

We're turning on the Apport crash handler for KDE programmes. Unlike the KDE crash handler it creates a full backtrace with debug symbols thanks to Launchpad. Will have to see if the bug team will manage to forward relevant reports upstream.

We finally got a shiny new website, thanks to Ryan.

I turned on compositing by default in kwin, still needs a patch to Compiz so we can use the same blacklist as it does. Not sure it'll stay on for final, just depends on how reliable it is out in the wild.

Worlds finest distributed revision control system, bzr decided to go with the world's finest toolkit for their GUI, I uploaded qbzr today.

Next week

Finally, congratulations to John and SakiFlux.

> Read More... | Digg This!

Great quote from Danimo's Chaos radio express interview when the topic Akonadi is discussed.

Since I am one of the developers invited to this year's KDE PIM developer meeting in Osnabrück, I am currently trying to improve my knowledge of Akonadi.

Being the maintainer of a rather small PIM application, kabcclient, which only uses one of the specialized APIs, the addressbook API KABC, I thought that a good way would be to start there.

KABC and its sibling KCal are based on the KResources framework, which means they get their data from plugable backends, so called resources.
Since they are part of the kdepimlibs module and have been released as part of KDE 4.0, they will still need to work once we have transitioned to Akonadi in KDE 4.1, or in other words they both need a way to get data from Akonadi instead of their usual sources like direct file access.

So I started to work on a KABC::Resource which operates on an Akonadi collection and a KCal::ResourceCalendar which does the same.

The one for addressbook data already works quite well, the other one still crashes a lot, you have been warned

While we are on the topic of compatability: Aaron writes from a conference in Australia that Akonadi is also being recommended to our peers in the GNOME project.
This makes a lot of sense because Akonadi is basically the next generation implementation of the principles they are currently using with E-D-S, the Evolution Data Server, quite similar to how D-Bus is a next generation implementation of concepts we previously used through DCOP.

Such a change is obviously quite some work, so it might make sense to do it as a series of smaller steps.
One such step could be to let their E-D-S application side APIs untouched but make them talk to Akonadi instead, a bit like how the embedded version transparently uses D-Bus instead of CORBA.

Most of the access patterns can be mapped quite easily, I have a compatible D-Bus service side implementation based on our traditional APIs (e.g. KABC) sitting in my local SVN repository (which I might commit to playground once I have finished its transition to Akonadi).

> Read More... | Digg This!

Like many KDE application, strigidaemon uses DBus to talk to other programs. Debugging inter-process communication is never very convenient and strigidaemon is no exception. So far, there are no unit tests for checking the quality of the DBus communication in Strigi. I set about to write some and found it was not so easy, so I'm documenting what I did for the benefit of all the other developers using DBus.

Here's a summary of what is needed to start debugging DBus communication. In the tests, we will start a private dbus-daemon for handling the communication between client and server. In our examples, strigidaemon is the server and we test by sending messages from the client (libstrigiqtdbus) to the server. We will be debugging the code that has not been installed, but resides in the build directory, since this is the normal situation for unit tests.

Step 1: clear the environment
Environment variables like PATH, LD_LIBRARY_PATH, XDG_DATA_DIRS, KDEDIRS all point to your installed software. We will clear them all and use absolute paths to make sure we are debugging the right version of our code. I do not want the unit tests to go wild with my production strigi index!

Clearing the environment can be done by calling unsetenv() for each environment variable. For strigidaemon, we still need HOME to be defined at the moment, so we do not clear that variable.

Step 2: start the dbus-daemon
You can start as many dbus-daemons as you like with dbus-launch. In the unit tests, we start dbus-launch with QProcess. dbus-launch launches dbus-daemon and returns immediately. This will print something like this:

These two variables tell your applications how to talk to the dbus-daemon. So we read the output from dbus-launch and pass the these variables in the environment of your unit test process.
Since the dbus-daemon has detached from dbus-launch, we need to remember its PID so we can stop our private DBus daemon it after we have finished testing.

Step 3: Start the daemon
We are starting strigidaemon. Because the unit test process has the right environment variables for talking to the daemon, strigidaemon can also do this. After starting strigidaemon we give it one second to become responsive to client calls.

Step 4: Run the tests
Now everything is set up to start testing. We have two processes running: dbus-daemon and strigidaemon. The API for doing the DBus calls is provided by the library libstrigiqtdbus. You could also use introspection to figure the API out, though. QtDBus picks up the connection settings for the private DBus daemon when you ask it for a session connection (QDBusConnection::sessionBus()).

At this point, you have to decide if you want to reuse the server process for all your tests. This is much faster, but could make it more difficult to debug some problems, since the root of the problem you see in one test may lie in a previous test.

Step 5: Stopping the daemons
strigidaemon did not detach, so we can stop it with QProcess::terminate(). To stop the DBus daemon, we call kill(dbuspid, 15), sleep one second and call kill(dbuspid, 9) to make sure dbus-daemon is terminated.

So now we have a way of doing DBus unit tests which takes care of starting and stopping the private DBus daemon and server program. It discards environment information and should not influence your running environment. All of this is achieved without needing a completely separate environment.

> Read More... | Digg This!