2.4. Connections between components

2.4.1. UI – PR

A single end user interacts with a single instance of the PR through a UI. The connection between them should be confidential. Transport of information between them should be fast enough that it does not stand in the way of a smooth user experience (this includes all aspects of transport, such as setting up a connection, applying measures to ensure confidentiality, etc).

The information items passing through the connection are usually quite small in terms of bytes when compared to current network bandwidth. The Deltas consist of alphanumeric information. Each Delta is the result of an end user action. There are no actions that lead to massive numbers of Deltas. Files can be handled as claim data: that is, the PDR is concerned with identities, not the actual items themselves.

The connection should also be reliable: whenever the end user fires up his UI, it should be able to connect to its PR.

Because of the nature of the UI (to enable an end user to access a PR) we assume that both components are active at the same time.

The connection should not only allow the UI to approach the PR; the PR should be able to initiate a contact, too. We need this to alert the end user to changes initiated by other end users.

2.4.2. PR – Store

A single PR interacts with a single Store (conceptually). We have not yet worked out an architecture where an end user deploys multiple devices. The simplest of architectures would be one where the Stores attached (through a PR) to UI’s on multiple devices, synchronise between them. This, however, will not provide a limited user experience when the user simultaneously uses multiple devices.

So for the time being we assume the unique association between a PR and a Store. The connection between them should be

  • Confidential

  • Reliable

  • Fast enough to handle the traffic resulting from several humans interacting through their UI (in the order of the number of relations a single person has).

Again, like with the connection between UI and PR, the required bandwidth is quite limited. Because of the nature of the Store (to persist information shed by the PR) we expect it to be active at the same time as the Store.

2.4.3. PR – PR

PR’s send Transactions to each other. However, as we do not require that PR is always available as an active process, the connection between them should handle this. Consequently, this connection should have the characteristics of a mailbox. We require the following non-functionals:

  1. The connection should be reliable;

  2. The connection should be confidential

  3. The connection should be restricted to two PRs.

  4. The connection should have a push-character: that is, the receiver should be notified after the sender has sent a Transaction.

  5. The connection should be reasonably fast, ideally fast enough to allow for a chat-like experience (i.e. time delay introduced by the channel should be low enough to provide a good user experience). This, however, is not a hard requirement.

  6. The connection should be able to handle the fact that end users will interact through mobile devices and do move around.

← Previous: Architecture: requirements | ↑ Up: Introduction to the PDR | ⌂ Home: Perspectives Technical Documentation | Next: Actual architecture and underlying technologies →