GPII Core Infrastructure
The GPII Core Infrastructure implements the GPII vision that any device is automatically configured based on the user's declared preferences. We call this Automatic Personalisation from Preferences (APfP) and initial work is being carried out in the EC Cloud4All project.
More detailed documentation can be found on GitHub.
- 1 Architecture
- 2 How it works
- 3 Trying the GPII Infrastructure
- 4 Making a solution work with the GPII infrastructure
The infrastructure's architecture is designed to be secure, scalable and flexible. It uses modern cloud-friendly and developer friendly technologies. It is critical that both commercial products and non-commercial tools can be easily integrated with minimal technical, IP and commercial barriers. Thus, standards as well as open source with permissive licences are used extensively. In addition, most components may be deployed in the cloud or locally in order to allow a wide range of installation scenarios. Thus the GPII can easily be deployed and allows access technology to be easily used.
This diagram shows the main components of the core architecture and their connections. The core architecture is responsible for identifying users  and recording and storing their preferences . The user's device and environment  are detected and matchmakers  access a database of known solutions to find the most appropriate way to configure the device to meet a user's preferences. lifecycle managers  then configure and run the various solutions on the device so it becomes as accessible as possible to the user. This may even involve installing new Assistive Technology on the device for the user.
How it works
The following illustrates what would happen when when a user approaches when a user approaches a GPII enabled device such as a Library PC or a Ticket machine. It use the current components of the GPII infrastructure and points to the code. Some of these details are likely to change or are not as "polished" as the final version will be.
For this example we assume our user, Sammy, has declared their preferences to the GPII infrastructure (no doubt using Personal Control Panel). Sammy is actually used as a test case for the GPII infrastructure.
User detection and identification 
There are several ways a user can be detected as supported by the available user listeners. Currently, for Windows these are a USB memory stick and RFID/NFC tags. In both cases a token is written on the media that identifies the user. Currently this is simply the users name eg "Sammy".
When the listener reads the token it "logs in" the user by creating a URL and using the RESTful API (it is also possible for developers to login in directly via HTTP). This kicks off the FLow Manger which orchestrates the other components to configure he device the user is on.
User preferences 
Our user's preferences are stored in a JSON file (though as server is possible). In this case they are all 'default' preferences that should be applied, whatever device Sammy is using. More specific preferences may override these defaults.
These preferences are given as URIs (ie not URLs and so don't exist if you HTTP GET) and they are so called "common terms" or "preference terms" that provide a canonical name for common settings. Many solutions may have their own names for the same preference/setting. The GPII project maintains a Preference Terms Dictionary tool to help manage these terms and ensure the same concept is uniquely named for the GPII use. This tool is new and the current list of terms can be found in this ISO24751-flat.json. It is also possible to have solution specific preferences listed in other formats.
Sammy's preferences declare he wants screen magnification amongst others and the flow manager collects these.
Device reporting 
Eventually the device reporting will detect and report what capabilities a device has based on what settings and access tools (AKA solutions) are available. It will also detect the device context (environmental settings). For now, the file installedSolutions.json lists all possible solutions on any device and the code knows what platform it is running on.
The Flow manager takes this information and passes it along with the user preferences to the Matchmaker
Matchmaking and the Solutions Registry 
Matchmaking is the process of figuring out what available settings and tools will give the user the best possible experience given their preferences. The Infrastructure supports different matchmakers with varying strategies with the main categories being statistical and rule-based. The match makers use a solutions registry that defines each solution, how to start and stop it and it's possible settings. Currently, the solutions registry is a file for each supported platform (Android, Darwin, Linux, web and wins32). so if Sammy is on a Windows machine the win32.json file is used.
The Solution Registry declares information for each solution including:
- Versions - what platforms it works on
- Lifecycle - how to start and stop it
- Settings - what settings are available and how they map to the preference terms and how to set/get them.
The mapping from preferences to settings uses transforms. These declaratively define the processing that needs to be carried out between names and values.
In Sammy's case the settings for windows magnifier are declared in the Solution Registry and provide instructions for starting the magnifier and changing it's settings given preference values
The FlowManger intitiates the matchmaking process, including any transformations and then passes the results to the Lifecycle Manager
Lifecycle Manager and Settings Handlers 
The Lifecycle Manager is responsible for configuring the device using the settings selected by the matchmaker. It delegates to the Lifecycle Handlers to start and stop programs / services and the Settings Handlers to actually configure them. Actually, the Solution registry entries declare most of the required functionality.
So for Sammy the magnifier is started and settings changed to give the preferences specified in his profile.
Restoring settings when has user finished
When the user has finished the Listener detects their departure and logs out using the RESTull API. In response the FlowManger directs the Life Cycle manager to restore the device state by rolling back all changes it made to the device configuration
So for Sammy the Magnifier is stopped and the magnifier settings are restores to their previous state (in case some one uses it without the GPII)
Trying the GPII Infrastructure
In order to try the core infrastructure see try the GPII Core Infrastructure.
Making a solution work with the GPII infrastructure
To benefit from the GPII so it can be automatically configured to meet a users preferences you can get a solution working with the GPII Core Infrastructure. See this Tutotial on Authoring Solutions and also Building A Simple Solution. The Implementation Tiger Team are also working in this areas so you might like to contact them.