[Architecture] Notes from today's architecture meeting

Antranig Basman 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 mailing list