AxAp is largely an exercise in system integration, so component selection is critical. Here are some of the items we're currently considering, organized into rough categories.

Audio Output

Using local support for audio output, AxAp should be able to generate and perform tones, voices, etc. This can be used for sensory substitution, sonification, user feedback, etc.

Data and image sonification are active and interesting research areas. Adding sonification to a directed graph of processing filters should allow AxAp to provide a wide range of transformations.


Emacspeak is an audio-enabled variant of Emacs. It provides a speech interface and an audio desktop, using speech and other sounds to let the user know what is going on. It's not clear whether or how AxAp could make use of Emacspeak, but it certainly seems worthy of investigation.


It would be interesting to couple audio output with touchscreen technology, as found on tablet computers. For example, the full-size iPad models have substantial (9.7 in.), multi-touch display screens. Using touch for input and audio for output, it might be possible to create interesting user interfaces for data exploration, etc.

However, the implementation details get a bit tricky. Even if we could wrest control of the touch events from the OS and browser, the latency of the resulting system could make it annoying or unusable. So, it might be necessary to write (difficult and unportable) driver-level code.

The vOICe

The vOICe is experimental software for navigational assistance, based on a form of sensory substitution. It turns an image into a left-to-right stereo sweep, mapping grayscale intensity to audio amplitude and vertical position to pitch. Although The vOICe is normally used to interpret video (e.g., from head-mounted camera), it has also been used to interpret static images.

Braille Output

Although most screen readers provide support for refreshable braille displays, their capabilities and default settings (e.g., encoding formats) may not match AxAp's needs. So, AxAp needs its own Braille support.

The BRLTTY suite handles a large (and easily extensible) set of Braille encoding formats. It provides support for a variety of refreshable braille displays and (through its built-in BrlAPI) could support use with other devices (e.g., braille embossers).

Code Analysis

Although most source code analysis tools only handle a single input language, a few popular tools are language-agnostic, to various degrees:

However, their command options and output format(s) are completely incompatible, so each one must be handled as a special case. Still, "wrapping" a useful tool is much easier than recreating it. Our preference would be to communicate with these tools by means of the new Language Server Protocol (LSP) and a set of Elixir-based wrapper functions. For details, see the Ctags, Enscript, Language Server Protocol, and Pygments breakout pages.


AxAp has a number of deployment goals, including:

  • controlling access to local resources
  • facilitating distributed development
  • efficient and flexible distribution

Docker provides clean, flexible, and powerful solutions to all of these and more. For details, see the Docker breakout page.

Web Access

AxAp needs to perform several kinds of web access. Different parts of the system will, for example:

  • interact with remote web sites and services
  • serve pages to local browsers and screen readers
  • support special-purpose single-page applications


Phoenix is a web application framework which is written in Elixir and runs on the Erlang virtual machine. It provides great support for concurrency and fault tolerance. Phoenix Channels support continuous, soft real-time interaction with client applications written in Elm, JavaScript, etc.

In many ways, Sinatra and Phoenix are quite similar. Both map HTTP requests to data structures, using Rack (or similar software), then process them through a pipeline of transformations. Both eschew magic, in favor of explicit declarations and commands. Elixir's syntax is also reminiscent of Ruby's.

However, the programming models diverge substantially in other ways. For example, Phoenix uses the actor model, message passing, pattern matching, persistent data structures, and syntactic macros. Sinatra, in contrast, uses monkey-patching, object-oriented programming, etc.


Sinatra is a Ruby-based domain specific language and web application library. It's a nice environment for prototyping:

  • easy and simple to use
  • flexible and extensible
  • free of magic and opinions
  • well supported by libraries

So, we expect to use Sinatra for a variety of prototyping tasks. However, the production system will use the Phoenix.


AxAp interacts with Web services and sites on behalf of the user, very much in the manner of a (forward) proxy server. So, it needs to be able to deal with issues such as authentication, data compression, and encryption.

Squid is a caching and forwarding web proxy server that seems to handle many of these issues. Alternatively, a set of web scraping (etc) libraries may provides a lighter-weight solution.

This wiki page is maintained by Rich Morin, an independent consultant specializing in software design, development, and documentation. Please feel free to email comments, inquiries, suggestions, etc!

Topic revision: r16 - 10 Aug 2016, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email