Release per March 31, 2020: v0.4.0

Version v0.4.0 corresponds to the sixth milestone in the project as supported by NLnet. This requires some explanation, as it is the fifth release since the beginning of the project on November 1 2019. See the releasenotes for v0.3.0.

Major changes

  1. Saving, caching, revisioning. The way entities (Context- and Role instances being the most important) are cached, serialised and stored as Couchdb documents with a revision history, has been refactored and described in two technical documents: Revision Handling and Serialising data structures.
  2. Indexed names. All Perspectives entities have a unique identifier. On top of that names can be used that have a different meaning depending on who uses them - operationalised as in which instance of the Perspective Distributed Runtime they are interpreted. usr:Me is an example. A role instance that comes with a model and binds to usr:Me turns out to be bound to each individual 'owning user' as it is interpreted. The current release provides a limited version of Indexed Names.
  3. Serialising new Context- and Role instances per perspective. If a user is added (by another user) to a Context instance, the first users' PDR must serialise that Context instance and send it to the PDR of the other user. But it must serialise just those roles and properties that the other user has a perspective on. The PDR is now capable of doing so. It constructs an ordered series of Deltas to the purpose. This work extends the work begun in the previous release, that handled updates. The current release handles new contexts or contexts that are new to a user.
  4. Setting up Channels. In the previous release Transactions were written to local channel databases. This release extends that work, adding Host and Port information to the Channel description and automatically setting up Couchdb replication between the various copies of a channel. We currently handle direct PDR-to-PDR replication and replication via a RelayServer. Documents in the channel are replicated based on who is the author.
  5. User identification handling. A PDR installation handles local accounts (storing passwords and account names) and user information for the 'owning user'. These two sources of user information are now matched. The PDR is now fully ready for multiple local accounts (users) and for multiple peers running their own PDR. Part of this work is that we can now quickly set up local accounts and have created a test user. All 282 tests now run for the test user.
  6. Deltas as Remote Procedure Calls. In a new technical design document we set out how Deltas can be conceived of as remote procedure calls. Whenever a user runs a 'DeltaFunction' that changes Perspectives state, we make sure all his peers with a perspective on the changed item execute the same function in their own environment. See the document Synchronisation.
  7. Unpacking a Transaction. A Transaction is an ordered set of Deltas. By executing the functions that the Delta represents (as a remote procedure call), we reconstitute the context- and role instances created or modified by a peer. This mechanism is now fully functional.
  8. Receiving incoming post. All Transactions sent by peers move into the 'post' database (a database per local user). The PDR 'listens' to changes in this database. It now handles all incoming Transactions automatically in a separate (Purescript) process. The overall architecture of the PDR is now three processes: one listening for calls on the internal channel (the same Javascript process as that the PDR runs in), on listening for calls on the TCP channel, and one listening for incoming Transactions.

A note on gun. We have considered gun as part of the Perspectives stack. Gun is a decentralised database written in Javascript. However, the nature of Perspectives is that we know exactly who should receive what update; moreover, users do not share the same database on the logical level. Each user has an unique perspective on each context, so users never share exactly the same representation of a particular context. We would have used gun as a way to set up a channel between two users. But this would be putting the horse behind the cart, because gun spreads information through the entire network of nodes. It works with a pub-sub model: each node takes what he needs. Perspectives can use destination information that is modelled on the highest level, on the level of actually shuffling data around. We wrote a column on the subject that you can find here: To Cut Nature at Its Joints.

Documentation

Various documents have been updated and three new design documents have been added:

  1. Revision Handling
  2. Locating peers
  3. Serialising data structures
  4. Synchronisation

Usage

To test drive the alpha version of the InPlace end user program, you will have to install the full development environment and build all projects.

Also, you'll have to install Couchdb. Perspectives development depends on version V2.1.1; however, we have good reason to believe the latest Couchdb version will work for you, too.

We refer you to the readme document of perspectives-react-integrated-client for instructions how to start the client.