#!/bin/lsh

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 invocation:

# 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:

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.

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

The old 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 pand tool.)

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.