Tag: bustle

I just released Bustle 0.2.3. The notable improvement is that you can now view a pair of D-Bus traffic logs side-by-side on the same chart. So if you’ve taken a trace of the session bus and the system bus, and want to see how the bus traffic matches up on the two, this is the release you’ve been waiting for! (If not, well, I made the ugly pink lines a more tasteful grey, and fixed some bugs you never noticed.)

While I was refactoring to support the second log, I would have liked to have been able to run Bustle in a “batch” mode to render straight to a file, and then run some kind of visual diff tool to compare the output of the branch versus the last release. Coincidentally, when I opened my inbox, I found a mail requesting the same feature! I imagine that this could come in handy for producing automated reports: maybe you’d have a weekly cron job that produces some stats about the traffic using bustle-count and, if it goes significantly up or down, sends an email to tick off or congratulate the relevant team as appropriate with an attached diagram. 😉 If anyone fancied having a crack at this, it shouldn’t be too hard.

A couple of days ago, I released version 0.2.1 of Bustle, someone’s favourite D-Bus profiler. As the version number suggests, there aren’t really any big new features; most of the changes just make it a bit nicer to use, like showing you all the bus names a service owns, ellipsizing strings, a slightly less spartan UI, etc. Having finally gotten around to cutting a release, I’ve started wondering what to work on next. There are various small things I have in mind, such as searching, filtering, integrating the various statistic tools (bustle-time and friends) into the UI, and so on, but it’d be nice to have a larger goal to work towards.

One recurring feature request is the ability to see messages’ arguments. This isn’t currently possible because the simple plain-text logs produced by the monitor (which is a variation on the theme of dbus-monitor --profile) only includes the message header. I’ve thought for a while that the right thing to do would be to log the raw dbus messages, together with a timestamp, but wasn’t sure what the files would look like. (Maybe shove the timestamps into the message headers?) Rob had a nice idea: why not log to pcap files? This avoids inventing a new format—the UI would just use libpcap and feed each message through the dbus parser—and would also let you look at the logs in WireShark, if you’re into that kind of thing. I’m hoping to find some time to give this a shot soon. (Maybe on a cold Christmas evening, in front of a fire?)

In the meantime, have a peek at what your D-Bus-using applications are up to, and let me know what’s missing!