[Architecture] Notes from today's architecture meeting
antranig.basman at colorado.edu
Wed Jul 23 14:20:43 EDT 2014
We didn't take running notes this time, and I thought I'd write a brief summary whilst the issues were fresh
in my mind.
A big point of business was Simon's pull request for updating our version of node.js on Windows to the
latest stable version (an 0.10.x version). This updates the node-ffi portability layer which is used in our
Windows-specific settings handlers. Whilst the code in the pull is now ready, we have run into difficulties
in that the rate of failure of our acceptance tests which use the SpiSettingsHandler has increased. These
were already failing at a certain rate, but some kinds of interactions within the node codebase have altered
the details of the relevant race condition so that these tests are now failing most of the time on most
machines. We need to find a route to stabilise these acceptance tests before this pull can be merged. This
issue is described at GPII-581.
The pull itself is being tracked at http://issues.gpii.net/browse/GPII-94 with links to the relevant pull
requests attached to the issue.
We decided to proceed with a simple stopgap solution based on a fixed timeout issued from within the
SpiSettingsHandler. This requires an architecture update which will be tracked at
http://issues.gpii.net/browse/GPII-434 (assigned to me). This should result in tests which are very slow but
hopefully more reliable. We can then continue with the GPII-581 work in a separate track.
GPII-581 raises the issues of how to manage our native dependencies on all of our platforms, but
particularly on Windows where the build chain is quite unstable and currently poorly understood. We
considered two linked issues:
i) How to modularise common dependencies amongst, for example, user listeners and the new listener required
by GPII-581, either
a) in terms of shared libraries, either statically or dynamically linked
b) or by centralising all of our listeners into a single monolithic process
ii) How to adopt a build chain which reliably works simply and portably at least amongst, say, versions of
Windows, but preferably even across all architecture
All of these listeners have a very similar internal architecture - they
1) Need to be launched with a command-line argument holding a "shared secret" (security requirement
discussed at http://bit.ly/1z3bS4T - GPII wiki, notes from San Diego March 2014, not yet implemented)
2) Need to listen to some "native gubbins" (whether it is the USB bus, an RFID tag, or the windows
desktop event queue)
3) Based on the gubbins, encode a JSON payload and post it to localhost over HTTP including the shared secret
A single monolithic process promises us a vastly simpler toolchain - since especially on Windows there are
numerous ways of compiling shared objects in a way which makes them link-incompatible with each other.
However, this raises the attack surface of the application and makes it hard to operate local security
policies which want to "obviously prohibit" certain kinds of native code running on the platform.
We decided to look into the relative merits of two "build file authoring systems",
http://www.cmake.org/ and https://github.com/TooTallNate/node-gyp . Some of these are discussed at
Various actions -
* I have a pull request open fixing our acceptance tests on Linux - this is being reviewed by Javi and Colin
- tracked at http://issues.gpii.net/browse/GPII-873
* Steve Lee is continuing to work on the RFID listener on Windows, and will report back on his build
experiences. We need to have some kind of build that can be operated by free tool chains such as MinGW even
if some development steps require proprietary tools
* Simon will look at build authoring systems and work with Steve L based on builds he comes up with as well
as our existing listener builds. He may also do some initial work exploring Windows event logs for GPII-581
More information about the Architecture