From wiki.gpii
Jump to: navigation, search


Listeners are processes that run on a platform and interact with the core GPII architecture. They monitor for events including user interactions. Initially we identified the requirement for USB and NFC listener which identify a user's token and pass that to the flow manager via RESTful URI to announce user log-on and logof events.

More recently we have found that it might be necessary to monitor WM_SETTINGSCHANGED on Windows in order to ensure settings have actually changed in response to the system. This has expanded the concept of listeners which could also potentially include the context awareness subsystem.

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

Security is a specific concern both operationally and in the perception of admins who will install GPII.

Release management is required so the latest and known to be secure version can be obtained and installed.

Build and install

Listeners are currently required and exists for Windows, Linux and Android. They are expected to be compiled and usually C/C++ based. A design goal is to avoid problems due to the complications introduced by shared libraries, especially runtime version control. This is a particular problem on Window as DLL is still alive and kicking even thought efforts like Windows SxS have attempted to address it. Thus we will build listeners using static libraries which will be created as a temporary part of the build process to further reduce any version issues at build time. This should give us well controlled images of known provenance (providing MD5 hashes can enhance that).


On Windows there are a number of build and debug systems that developers might use. These include the commercial Visual Studio, MinGW's gdb or IDEs like Code::Blocks. We certainly can't require commercial software be used so should support GDB or open source IDEs. The NFC build chain needs to use dlltool (included in MinGW core). Accordingly we will explore using a pre-build tool like CMake or Gyp.

An MSI installer would be ideal and almost certainly preferred by enterprise users of GPII. However the open tool, Wix, is considered hard to use. InnoSetup is a mature gui or command line based tool (with declarative syntax or script), and chocolaty offers apt-get style package mangement but we would want our own

CMake vs Gyp

We decided to look into the relative merits of two build file authoring/portability systems: CMake and Gyp. Some of these are discussed at


Q If we create everything ourselves and use few 3rd party libraries that we need to build then why not use the portable gcc toolchain for everything, possibly enhanced with the Code::Blocks IDE? A There may still be build differences between platforms, though autoconf etc could perhaps manage them

  • we are likely to need to add native extensions to Node.js for the interface to listeners this will naturaly use node-gyp. This might be usable for building listeners too
  • 3rd party libraries usually only come with xcode/vstudio builds.
  • There are free versions of all platform buildtools which we can target to give native build / debug
  • can we target open source IDEs like Code::Block?
  • What about Android
  • MS are unifying the dev/build toolchain for Windows, Windows Store and Phone and are working with CMake



  • Mature
  • extension modules
  • works with CTest and CDash automated test dashboard


  • imperative




  • only gcc/xcode/vcproj according to platform. win is MSVC only (at least for node-gyp built node extensions as node is built with MSVC)
  • no errors for missing deps
  • fairly immature
  • Somewhat limited compared to CMake , assumes python scripts support
  • JSON syntax can get DEEPLY nested

Interface Listeners to GPII core

TBD - how ? "encode a JSON payload and post it to localhost over HTTP including the shared secret"