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.
Using local support for audio output,
AxAp should be able to generate and perform tones, voices, etc.
This can be used for sensory substitution
, 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.
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
as found on tablet computers
For example, the full-size iPad
have substantial (9.7 in.), multi-touch
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.
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.
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
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
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
Language Server Protocol
, and Pygments
AxAp has a number of deployment goals, including:
- controlling access to local resources
- facilitating distributed development
- efficient and flexible distribution
provides clean, flexible, and powerful solutions
to all of these and more.
For details, see the Docker breakout page
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
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
support continuous, soft real-time interaction
with client applications written in Elm
In many ways, Sinatra and Phoenix are quite similar.
Both map HTTP requests to data structures
(or similar software),
then process them through a pipeline of transformations.
Both eschew magic
, in favor of explicit declarations and commands.
is also reminiscent of Ruby's.
However, the programming models diverge substantially in other ways.
For example, Phoenix uses the actor model
, pattern matching
persistent data structures
, and syntactic macros
Sinatra, in contrast, uses monkey-patching
is a Ruby
domain specific language
and web application
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
, data compression
is a caching and forwarding web proxy server
that seems to handle many of these issues.
Alternatively, a set of web scraping
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!