Basic Concepts

An OVE server installation supports multiple spaces. A space is a collection of monitors, which may be attached to different computers, that together form a single display. OVE is designed to be used in Large High Resolution Display environments; but, it is also suitable for use on much smaller displays with a single or a few monitors.

In each space, OVE runs within a number of clients. An OVE client is a browser window and typically runs full-screen on a single screen. A screen can span a single monitor or can span multiple monitors that are attached to the same computer. The arrangement of clients is described in the Spaces.json file. Each client has its own geometry which is a combination of its height, width, and 2D coordinates (x, y). The values for x and y are equal to (0, 0) at the top-left corner of the space and increase on a per pixel basis from left to right and top to bottom, respectively.

An OVE application (or app) includes server-side and client-side components. Each of the OVE Apps confirm to a common structure and provide a way to display a distinct form of commonly used content (subject to the limitations described in the list of pitfalls to avoid).

Each individual instance of an OVE app is designed to run within its own section. Sections may span multiple clients and can overlap. Sections are rectangular regions within an oveCanvas. Each section has its own geometry which is a combination of its height, width, and 2D coordinates (x, y). The geometry describes the region on which a section is deployed on an oveCanvas. An oveCanvas can also have groups of one or more sections and groups.

Each individual OVE app can have its own configuration (or config) defined within a config.json. The config is used to define named states other app-specific configuration, which are common to all app instances. Each individual instance of an OVE app can have its own state (which can be accessed using APIs exposed by each app).

Each OVE section does not have a background colour, and a wide majority of the apps have transparent backgrounds making it possible to overlay content from one app above another. This for example, makes it possible to use the HTML App to display a legend for a chart or a network. All OVE apps also accept an opacity property (at creation time or when updated), making it possible to control the opacity of overlapping content.

../_images/concepts.svg

Runtime environment

Each OVE client displays the view page of OVE core. When a section is created, a corresponding iframe is created within each client that it is associated with. The view of the corresponding app is loaded into this iframe.

In addition to these views, apps may present a control page that can be accessed directly through a web browser; this controller can communicate with the views running in clients using WebSockets.

When the iframe representing a section is created, its margin CSS property is used to position it correctly, and the window.ove.geometry object is set so that each instance of an app running within each iframe can determine what to display.

Peer nodes of OVE core

OVE core accepts registration of peer nodes using the http://OVE_CORE_HOST:PORT/peers API method. Once registered OVE peers will cross-post messages that are broadcasted using WebSockets. Peer nodes of OVE serve two purposes, high availability (HA) or distribution of workload.

For a HA deployment, OVE also provides a Persistence Service which can be used to replicate server-side state among peers. This service can be registered with OVE core or any OVE application as explained in the documentation. In a HA deployment each peer can take up the role of being the master and therefore they can also be fronted by a load balancer.

In terms of distributing workload, OVE is capable of offloading the messaging subsystem to a different peer either for a single app or a group of apps. OVE can have any number of such peers as long as they are registered and they would all be in sync with the master. Unlike in a HA deployment, these peers are slaves and cannot be fronted by a load balancer as they would be serving dedicated apps.

All peer-to-peer communication use WebSockets.