Flow Manager Modes

The Flow Manager can be operated in three distinct modes, depending on the deployment geometry of the system and, eventually, the stated comfort level of the user in regards to whether they prefer to keep their preference data entirely in the cloud or localized to a particular collection of devices. These three Flow Manager modes include:

  1. The all-local mode, where a locally-installed Flow Manager is responsible for retrieving preferences (either from the Preferences Server or from the user token device itself) and delegating to locally-installed matchmaking components as well as the cloud-based matchmaking services: Statistical and Rule Based matchmaker algorithms.
  2. The all-cloud mode, where standalone applications, web applications, and other server-based tools use the cloud-based Flow Manager for preferences retrieval, matchmaking, and settings transformation. These applications then perform their own self-adaptations based on the privacy-filtered, transformed settings returned from the cloud-based Flow Manager.
  3. The hybrid (or “local untrusted”) mode, where the locally-installed Flow Manager collaborates with its cloud-based counterpart and the cloud-based Matchmakers to perform the preferences retrieval, matchmaking, and transformation-into-settings tasks. This mode (default) is intended to ensure a minimum of overall latency while minimizing the amount of personal information (drawn from raw preference sets) that is passed between local and cloud environments.

The Local Flow Manager

The locally-installed instance of the FM is responsible for responding to key-in/out events (fired from the User Listener component, discussed below) and orchestrating the local parts of the personalization process. Specifically, this includes:

  1. Delegating to the locally-installed Device Reporter to gather device information such as the list of solutions that are installed on the user’s device
  2. Delegating to the Device Reporter’s sensors to gather environmental data, such as time of day and ambient brightness and noise levels
  3. Establishing a persistent bus for streaming real-time contextual data from the Context Aware Server
  4. Invoking the cloud-based FM to perform key preferences-based tasks in the cloud, such as fetching preferences, matchmaking, and transforming preferences into settings. This way, the user’s raw preference sets are not stored or transmitted to the local device (unless the user prefers a local-only topology)
  5. Invoking the Lifecycle Manager, which will configure, snapshot, and launch the settings and solutions determined by the matchmaking process
  6. Providing a persistent, bi-directional communication channel that enables the PMT and Personal Control Panel (PCP) to post preference change notifications whenever a user edits their preference set (in the case of the PMT) or makes a session-specific modification to the current adaptation (in the case of the PCP) and distributing these notifications to other components, such as the browser extensions and Lifecycle Manager
  7. Reversing this process when the user keys out

The Cloud-Based Flow Manager

As its name suggests, the Cloud-Based FM is an instance of the Flow Manager (i.e. sharing the same code base as the local instance, but with a different configuration profile) that runs as a server in the cloud. This version of the FM is designed to support two distinct use cases:

  1. Brokering potentially-sensitive tasks, such as fetching preferences, matchmaking, and transforming preferences into solutions in a manner that ensures a user’s N&P set stays in the cloud, rather than being delivered to a potentially insecure device like a public workstation or kiosk
  2. Supporting the integration of self-adaptive applications (native or web-based) and platforms that are unable to run the full suite of locally-installed Cloud4all/GPII components (due to system-level or institutional constraints)

Push vs. Pull Personalization

The Cloud4all/GPII architecture implements two different approaches to configuring an application: push and pull.

Push is typically appropriate for locally-installed native assistive technologies running on PC or mobile OS (e.g. JAWS, Talkback, and Read & Write Gold), is a push-based model where the applications have no direct dependence on, or knowledge of, Cloud4all/GPII. When a user keys in, the local Flow Manager and the Lifecycle Manager push the appropriate settings to each application (via the Settings Handlers) and then launch them.

With the pull approach, applications pull settings from the FM (either local or cloud-based) on demand. This is typically necessary for standalone native applications (such as Mobile Accessibility on Android) or adaptable web apps, which don’t store their settings in a way that can be externally modified and which only need to be configured in the case when the user actually browses to the site.