GPII Core Infrastructure

From wiki.gpii
Jump to: navigation, search

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 and there are also pointers to external docs.

Architecture

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.

GPII Program Flow-small.png

This diagram shows the main components of the core architecture and their connections. The core architecture is responsible for identifying users [1] and recording and storing their preferences [2]. The user's device and environment [3] are detected and matchmakers [4] access a database of known solutions to find the most appropriate way to configure the device to meet a user's preferences. lifecycle managers [5] 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 Overview of the Architecture introduces these components in more detail and outlines how they work together. There is also a more Detailed Tour of the Architecture.

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.

Example user

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 [1]

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 [2]

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 [3]

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 [4]

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.

Transforms

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 [5]

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.