Static Accessibility and Generative Accessibility
For the first time in a while, I'm setting up bluetooth tethering on a new machine (unlike wifi tethering, I can leave a bluetooth connection up all day long without noticeably affecting my phone's battery life). For reasons outlined here, I do this using short snippets of shell script to bring the bluetooth connection up and down. In the past, this meant calling the
pand CLI tool, but that's changed in the latest version of
bluez. As found in the Arch Wiki's guide:
$ dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF org.bluez.Network1.Connect string:'nap'
Compare this to the previous
# pand -E -S -c AA:BB:CC:DD:EE:FF -e bnep0
Now, I don't know what the logic behind changing to a pure-
dbus interface between
bluez 4 and
bluez 5 was. Presumably there was a good reason, but at the same time a few important things have been lost:
- The only documentation about doing this I could find on the internet was the above mentioned Arch Wiki guide. If that hadn't existed, the only way of discovering how to do this would have been a combination interrogating bluez' dbus interface with dbus debugging tools and reading the source to bluez - and it would have been necessary to somehow find out that bluez now communicates exclusively over dbus, something I only learned by paging back several pages into the news section of the official bluez website. By contrast, there exist multiple tutorials for accomplishing tethering using
pand, and additionally it'd be possible to see what utilities get installed with bluez and read their
manpages to discover the whole procedure.
blueznow hard-depends on dbus.
- There's no longer a simple way as a user of bluez to have a script or program wait for the connection to succeed or fail. With
pandit was possible to just invoke the tool, and examine its exit status afterwards.
It's most likely that the reasoning behind this change is that the dbus interface is better suited for building GUI bluetooth management applets, which make bluetooth functionality accessible to the nontechnical masses. In essence, we're seeing a change from generative accessibility to static accessibility.
Wait, what? Let me 'splain:
Static accessibility is what is typically meant by 'it just works', or the 'appliance' approach. There is a single task and way of performing the task the tool implements. No additional capabilities are possible, but the ones provided are easy to use and foolproof in operation. It's accessible because it's easy to pick up and use without learning anything, and static because it can be used for only one task.
dbus interface represents the static approach: it's a low-level interface intended to be hard-wired into a certain type of larger system. It has definite ideas about the kind of use-case (making a bluetooth icon in a system tray able to control bluetooth connections). The main concern is that there is a very specific experience that needs to be provided, and anything not on the critical path to creating that experience is of secondary importance. Hence "static": The tool makes a capability accessible (as in not requiring training or documentation) in a specific way, and only that way.
Generative accessibility is a major component of what's often referred to as 'hackability' or 'the unix way'. The tool provides a certain ability without providing any policy of how to use that ability (e.g. a flathead screwdriver allows applying torque to opposite sides of a slot, a capability that can be used either to turn screws or crack open the case of a malfunctioning appliance), and provides the ability through a combination of documentation and an empirically discoverable interface the ability to be easily used in novel ways in conjunction with other tools. It's accessible because it's easy to learn to use, and generative because it can be used in creative and unexpected ways.
pand approach represents the generative approach: rather than providing an internal component for a certain experience, it provides a tool for controlling bluetooth network interfaces (this is a similar idea to the separation of mechanism and policy principle). The tool is designed to make the typical operations of bringing up and taking down an interface for a specific device simple, and is well (or at least basically) documented. This approach is generative because it enables creativity and use cases not forseen by the providers of the tool. In this case,
pand could be used to build both GUI bluetooth connection managers, and the small shell script that lets me control tethering on my OpenPandora with a few quick keystrokes, all without having to be a developer on either the
bluez project or Gnome/Android/KDE.
(As a sidebar, I'll note that in this specific case, simply documenting the
dbus API to
bluez properly would change things significantly, restoring much of what was lost by the elimination of the
If the value judgement I'm making here isn't already obvious, let me spell it out: for a project like bluez, Generative Accessibility is superior to Static Accessibility. Static Accessibility can be easily built on top of Generative Accessibility, but not vice versa. It's the easy hackability of tools like
pand that has made Linux what it is today, and there's no defensible reason to undo the layered architecture that makes that hackability possible in the myopic pursuit of one particular type of user experience.