As a result of researching topics for PyCon keynotes, I've been digging a bit into the One Laptop Per Child project. Being based on Python, essentially seeking to provide a 'Python operating environment', it looked quite interesting. I noticed that they plan to make heavy use of localized wireless grids for children to interact, essentially multicast service-locating DNS the software for which is called Avahi. The Avahi software implements the zeroconf or Bonjour/Rendevous functionality and sits on top of the D-BUS, a Unix desktop bus for interprocess communications within the same machine. There is a Python module for interfacing to D-BUS, both as a client and a server.
And so this past Saturday at the DFW Pythoneers hands-on session, I pulled together some demo code and we walked through this technology, D-BUS, HAL, Avahi, notification-daemon, in Python.
D-BUS is both a library and a daemon. The library implements point-to-point message-based communication between processes on the same machine. The daemon adds a service registration ability and can start dormant services upon the arrival of requests. Now it turns out that you can start as many daemons and therefore buses as you wish. Usually there are two: a system bus started at boot time for exchanging messages about hardware availability and such, and a session bus started at user login time for desktop objects to talk among themselves.
Python programs can participate on either of these buses, with quite seamless handling of datatypes and asynchronous I/O using glib (wishing for a Twisted reactor myself). Buses aren't of much use though unless there is something to which to talk which leads us to HAL.
One of the services that resides on the system bus is HAL, the Hardware Abstraction Layer. Using Python, it appears as a Device Manager mapping (keys, values, items) of device names to device instances, and each device instance has a mapping of properties (name -> value) and capabilities (set of well-known strings). Both the manager and device objects support callbacks upon the addition/removal/change of devices and properties.
In my demo code, I show how to monitor and manipulate the brightness of my laptop LCD display, as well as to detect the insertion of a USB flash drive. But if you're going to be responding to hardware events, you often want to notify and perhaps interact with the user, which means we need something like the notification daemon.
About the Notification Daemon
Another service that resides on the bus, although on the session but not the system bus, is the notification daemon. Not a catchy name it comes associated with the 'libnotify' component. Using it your Python-based services can quietly display one of those non-focus-stealing balloons in the lower-right corner of the screen. The balloons can have lifetimes or require user acknowledgement. Also supported are icons/graphics and sound although I didn't play with those in my demo code.
But getting back to my original goal, the Avahi multicast DNS service. Our group began to run out of time but Avahi is also accessible on the system bus. This means a Python program could stay aware of what machines are in the neighborhood and, combined with the notification daemon alert you.
I hope to further investigate tying these services together, along with the Festival/Cepstral speech synthesis interface I'm developing for Python and it would be really cool if we could have something working in time for PyCon. Something like the groupware programs the Mac users have to share live notes on talks but this time for us Linux people as well. ;-)
The source for the demo, rough code sketched out in an evening, is available in the DFW Pythoneers subversion repository.