J5’s Blog

A few more bugs were found in the last D-Bus release that warent a new point release. Some typos were fixed in the Python bindings (thanks Dimitur) and now I am waiting for Colin to send me a patch that renames the new SELinux API for getting a message’s context. Better to get the rename out before people start using the API. So sometime tonight there should be a release of D-Bus 0.35.2.

Well, I’ve gone and did it. Released a package and then released a working package a half a day (or should I say night) later. The 0.35 package wouldn’t compile because I had inadvertantly shiped with a generated file instead of its template. Unfortunately swapping the files in EXTRA_DIST caused distcheck to fail and I found myself hunting down $(srcdir) problems. Mix that with a flaky internet connection and I just lost three hours of my life. So it is three o’clock in the morning and I finaly got the fixed release out. Thank you Nalin for booking the Duck Tour at 4:00pm instead of your first suggested 9:00am.

Hopefully now I can stop talking about D-Bus so much and move on to more interesting topics.

After fighting with distcheck for a bit I was able to get the new release out the door. Head over to the D-Bus wiki to check out what is new. My tutorial on my own server is out of date and will be removed. The new tutoral is up in its usual location. Have fun hacking.

I’m almost finished checking in all the patches that need to go in before the next release of D-Bus. I plan on trolling bugzilla tomorrow to see if there are any lingering bug fixes and also check the mailing list for any of my own patches that were approved but I did not apply yet. I think there is one. After that I can do the release.

The good news is I just checked in a tutorial for Python and noticed that the G-Lib section was filled out also. Yay. Now people can stop complaining that they can’t find docs. Well at least they will start complaining on a higher level now that some of the basics are covered ;-). I noticed that only Havoc has permissions on the doc directory on the freedesktop server so I uploaded the tutorial here until I can get him to upload it. One caveat is that some of the examples will only work with the bindings in CVS (or the release I should get out tomorrow). Ah, if only for the price of progress. I’m thinking of backporting the changes to FC-4.

DBUS_VERBOSE rocks, if a bit verbosely

A couple of tips on debugging D-Bus tests:

• make check is your friend
• use bus/bus-test test/data for running the bus tests
• use dbus/dbus-test test/data for running the dbus library tests
• to get verbose output use DBUS_VERBOSE=1 bus/bus-test test/data &> results.log - don’t let it be piped to stdout or you will be waiting for a long time for your terminal to update and will lose the most important information to your scroll buffer
• dispatch.c(bus_dispatch_test) is the most important starting point for bus test. Comment out the tests you don’t need when debugging. This will make sure your turnaround times are a bit faster and your output a little more terse (one test gave me > 300 megs of logs in verbose mode)
• configure options I use to test D-Bus - –enable-tests=yes –enable-verbose-mode=yes –enable-asserts=yes

The verbose output allowed me to find out that my activation failure tests were succeeding once and then failing on the next iteration. After putting in a few more verbose ouputs in strategic locations I was able to determine that on the second pass the bus was still in a state where it was waiting for the service to activate even though it had failed the first time around. It was then determined that at the new point of failure we had added, which can fail if comand line arguments to the activated program has an unterminated quote, we were not taking the pending activation out of the hash. This screwed up the state of bus which still thought it was waiting for the service to activate when in fact the service had failed to activate and should have been taken out of the pending state. Simply taking the pending activation out of the hash fixed the problem and my test now passes.

This is why we write a test suite. This bug would not have been caught otherwise. The two tests took me an hour to write but perhaps save hours of searching if this bug had turned up in the wild with no test cases. Yes they can be a pain to write and not much fun but they are worth every bit of effort that it takes to write them.

Rodrigo’s patch will go in with my fixes and then I am going to focus on fixing a python bug when removing signal handlers and then I should be ready to do the release I planned last week.

I created two more tests for Rodrigo’s auto-start command line parsing code. The first one which spawns a service over the bus and has it send its arguments in the reply works flawlessly so I was about to say it is ready to be checked into CVS.

That was until I created a second test that spawned a service with faulty quoting on the command line. This should produce an invalid argument error over the bus but instead I get a timeout. This is not an error in Rodrigo’s code as far as I can tell but a bug in dbus that seems to not want to propigate this error. I can confirm that it issues the command to send it but it never gets into the test suites queue and instead we timeout waiting for a reply. Unfortunatly until I figure this out I can’t check the code in.

I’m running the testsuite with DBUS_VERBOSE=1 which even with just the one test enabled produced 317M of debug spew. I need to figure out a way to turn off the out of memory tests so I can debug what is going wrong a bit quicker.

UPDATE:

It actually succeeds once and then timesout on the last call. Is this another manifestation of the old activation bug that was fixed recently?

After fighting with Pyrex and getting modules to share class definitions I was able to rip dbus-glib into its own bindings. In order to integrate a new mainloop all a module writter has to do is:

import dbus

setattr(dbus, "_dbus_mainloop_setup_function", _setup_function)


where the setup function takes a dbus_bindings.Connection object. The setup function then takes that Connection object and in the binding backend, extracts the DBusConnection pointer and runs the method it uses to do the setup. In glib’s case it is dbus_connection_setup_with_g_main. I’ll need to think of a way to pass in extra parameters to the setup function. For instance a person may wish to setup the connection on something other than the main loop context.

Anyway I will check in the code tomorrow. Right now I need some sleep and have a forty minute drive home.

I’m going over some structural changes to the python bindings and also want to get some documentation going in the tutorial for both that the glib bindings.

Changes happening in next release which may make some people cry:

• service is being taken out of the main module and placed in dbus.service - some people needed to use the message sending functionality in Python < 2.4 and the decorator stuff in the services module was making their lives difficult. While I don't pretend to be trying to keep compatability with Python versions < 2.4 it was a good idea none the less to break the service stuff out.
• dbus.service.Service is now renamed to dbus.service.Name to keep in the lingo of D-Bus.
• The outward facing API for glib integration will be placed in its own module in preperation for allowing other mainloops including a generic one (i.e. no more glib dependancies in the bindings if you don’t want them). Getting the glib mainloop should be as easy as import dbus.glib. I plan on writting a generic mainloop which will become the default. Other mainloop modules (such as qt) should be easy to create.
• version will be changed to (0.41.0) to reflect the changes

All in all not too much changes will need to be done but it will be a bit of porting pain. Since Fedora Core 4 is the only distro to ship with 0.33 I’m hoping there will not be too many people using the service stuff. Clients on the bus should just need something along these lines:

import dbus
ver = getattr(dbus, 'version', (0, 0, 0))
if ver >= (0, 41, 0):
    import dbus.glib

API changes are a pain but I would rather break now than after 1.0.

I should be doing a D-Bus release this weekend which will integrate a whole slew of fixes from bugzilla, sorta/kida/most likely lock down the glib bindings API, whip the python bindings into better shape and get things ready to be the “recommend” release for Gnome 2.12. I figure one more release after that where things may change. In any case I don’t predict any major API changes from then and now in D-Bus proper. If anything we are only going to add extra API but I predict even that will be kept to a minimum.

After all of that we are almost on the home stretch to 1.0. I want to get feedback from the Qt guys. TODO has been whittling away and bugs are being fixed so things are going smoothly. You, got to love progress.

Reading Bryan Clark’s blog and then back to Rodrigo’s blog and finally coming back to the Spec itself. I can’t help but think that we are going down a dangerous road that if adopted by the Gnome developer community without some forethought could lead to a total train reck.

A bit of back-story

You see I am a huge advocate of interoperability where it makes sense. One of the best ways to get there is to define a specification that everyone (or at least the majority) agrees upon. Why is it then that I find myself fighting specifications lately? It seems that writing specifications is the new in thing to do with terms like “generic solution” and “unification”, but without a solid engineering basis these specs often become bloated and unfocused. The problem is it is easy to dream up a super awesome cool system that solves the worlds problems. Engineering it so it is useful is another story altogether. Generally the more complex the spec, the less use anyone is going to get out of it (and the less compliant implementations will be).

Back to desktop notification

Now I am not saying the desktop notification spec is that bad. I have seen far worse specs. The desktop notification spec is written up by some smart guys and it has a good basis to work on. It does have a defined problem it is solving, all be it not as focused as I would like to see.

It grows larger by the day and I don’t want to see it go down the road of bloat that other specs have. I mean come on, a notification on how much trash you have? I just dumped my trash. I don’t need to be told what I just did. Or weather changes? Having a notification popup every time the weather changes a slight bit is just silly - “Oh by the way it is sunny out so you can go outside and ignore every other annoying message I will throw up on your desktop”. To be fair Rodrigo was most likely just playing around with the code and none of that would actually get into the desktop proper.

If we are serious about getting these notifications into GNOME we need to step back, take a breather and set some constraints on what it means to be a notification. What services do we really want to use the system for? How do users interact with these notifications? How can we pare down the spec in relation to these constraints? Remember it is easier to add to a spec once it has been agreed upon than take away from it.

I think Bryan has the right idea. Pick a few apps and write notifications for them. Once we have defined what is actually needed we can then tack down only those parts of the specs that were used. As our needs grow we can add more definition. This way we will be able to keep on the right track, make it easier for others to adopt and not end up where so many other over engineered specs have gone to die.