Release per June 12, 2020: v0.5.0

Version v0.5.0 corresponds to the sixth milestone in the project as supported by NLnet.

This release has turned out to be quite massive. The reason is that we set ourselves this clear goal: to be able to establish 'first contact' between two installations and then have information flow bidirectional between them. While deceptively simple, this turned out to be the acid test for the PDR, revealing many pieces yet missing from the puzzle. It required a lot of thought and new mechanisms, as can be seen from the no less than 10 new design documents detailing decisions and technical matter. This release contains them all.

However, with this release we've fulfilled the primary objective of this subproject financed by NLnet: the alpha version of the Perspectives Distributed Runtime (PDR).

As proof of existence we supply a short video showing how, from within a very simple Chat application, an invitation is generated by one user. This invitation - being a JSON file - is then dragged across the screen to the main window of another PDR installation. Once landed, a replication of the invitation is constructed automatically for the second user. He then accepts the invitation by putting himself in the role of Invitee (causing a role binding). Subsequently, this role binding and some information about himself is sent back to the original user through the automatic channel set up between them. From that point on, they can chat. A detailed explanation of why this is a test of many of Perspectives' essential mechanisms can be found here.

Major changes

  1. Indexed Names. Some names have a different meaning, depending on who uses them. 'Home' is an outstanding example. In Perspectives, 'Me' would be an example. For each end user, this translates to the identifier he is, well, identified with. A modeller may introduced indexed names for roles and for contexts. This is described in the document Indexed Names. This subject ties in with user accounts and user-specific databases.
  2. Serialising as JSON. In a previous release we published code that serialises context- and role instances as sets of Deltas. This is the preferred (normal) way of distributing contexts and roles between peers. However, if two peers are not yet connected, they cannot use this mechanism. Instead they fall back on JSON serialisation, using it to transfer an 'invitation' context and its roles.
  3. Queries can now result in types. Up till version v0.4.0, query results could be instances of roles and contexts, or values. This version introduces keywords for the Perspectives Language that return role- and context types: contextType and roleTypes. We also introduce a keyword with a type parameter: specialisesRoleType. In the future, we will extend the language with keywords for View-, Action- and Property types. This is an important step, as it makes model reflection possible (the original Perspectives implementation in Javascript supported full model reflection). As a consequence, the entire query compiler was rewritten.
  4. User Role comparison. Role types can be compared in the sense that one role can be a specialisation of another. An important method to specialise roles is by including aspect roles. Up till now, we only compared a role's properties to establish it relationship with another role. For user roles, we now include the role's perspectives, too.
  5. Deltas on bindings. In Perspectives, the properties of a Role’s binding are as accessible as if they were the Role’s own properties. The modeller may add a View to an Action that includes any of these binding properties. And this applies to the binding of the binding, recursively. This means that through role binding, properties on Role instances outside the context are visible (for a user) without an explicit query. Yet we must ship a Delta describing a change to such a property or role to such users. This issue is correctly addressed now.
  6. Contextualising Actions. A user role may be given an aspect role. Such an aspect role is in all respects an ordinary role. The role inherits from the aspect all its properties and its perspectives. However, these perspectives will have been settled on roles in the original context, that of the aspect role. Contextualising refers to the mechanism that maps these perspectives on roles in the context of the role with the aspect. See the document Contextualizing for a design discussion.
  7. Serialise subnetworks as a consequence of a new binding. Adding roles and properties will build up isolated contexts. However large these may be, their structure is simple. Only by creating bindings between roles can we build more complicated structures. In general, the data structures that we can create are graphs of contexts and roles. It follows that by adding a single binding, an end user causes his PDR to serialise an entire subnetwork and send it to peers.
  8. Computed user roles can have a perspective. Up till now, we had reserved perspectives (actions on a role) for enumerated user roles. However, it has become clear that we need them for calculated user roles, too. The prime example is the Guest user role (by convention every user takes on the Guest user role if he has no other role in a context). This will give a visitor some perspective on a context. However, who is that Guest? Turns out that it is very convenient to have a query give the answer.
  9. On-the-fly model loading. There are two routes that bring contexts and roles to the PDR with types that it may not be familiar with: contexts serialised as Json and Transactions. It turns out that we must then first fetch the model from a repository. Hence, on-the-fly model loading.

Minor changes

  1. Composing instance- and type level functions. The query language of Perspectives allows the modeller to traverse the network of context- and role instances. However, the types defined in a Perspectives Model form a network (directed Graph), too. The source code of Perspectives contains many examples of traversals through this network. In the future, we may empower the modeller with additional means to construct queries over the type network, too. A major difference between the two types of queries is that (currently) we track dependencies for instance level queries, so we can have the PDR push updates to the client. We don't do that on the type level (yet). Anyway: in the PDR source code we have use cases to combine queries over the two types of network. We have constructed a principled way to do so and have detailed that in the document Compose Instance and Type Level Functions.
  2. Prefixed names. All types and individuals in the Perspectives Universe are identified by qualified identifiers. These are identifiers that are prefixed by a namespace. In the source text of model files, we may declare and use prefixes for convenience. The details of when prefixes may be used are explained in Expanding prefixed names.
  3. Using a Calculated Role as a binding type. Role instances can be bound to other role instances. Such instances have EnumeratedRoleTypes. A modeller may constrain the possible bindings on an EnumeratedRoleType by specifying a type. This may be an EnumeratedRoleType, but it can also be a CalculatedRoleType. This latter possibility has now been implemented.
  4. External functions can now be used as regular query functions. Previously, functions applied with callExternal could only be used as the entire expression following the = in a Calculated Role or Property. It is now possible to use such functions anywhere in the composition that makes up a query. Being a regular Query expression, they can also be used in the right hand side of assignments and all other places where query expressions are allowed.
  5. Perspective on external role. The external role was treated like an ordinary role in the Query Compiler, but is now correctly handled.
  6. Invert query steps consisting of external functions. External functions (Core or Foreign (the latter are not yet implemented)) add functionality for the modeller. As such functions can now be used in queries, too, we should be able to invert those steps, just like we can with built-in functions like context.
  7. binds operator for PL. In order to implement Calculated roles that correctly handle indexed contexts, we must be able to filter on what a role is bound to. Hence a new keyword.
  8. Make update operations idempotent. How should we handle a delta that tells us to create a context that already exists? Actually, we should not do anything, lest we risk losing information. All update functions are now idempotent.
  9. Compile a getter for a property on a role graph in design time. Imagine a role telescope with a property on the nth- binding. To get at that property, we have to apply the binding operator n times. This we can calculate in design time. We then don't have to search in runtime.

Documentation

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

  1. Compose Instance and Type Level Functions
  2. Indexed Names
  3. Expanding prefixed names
  4. Parsing and Compiling Models
  5. User and System Identifier
  6. The practical guide to writing a module with core external functions
  7. Query Inversion is updated with an exposition of some difficult cases: Perspectives Language variables, Calculated Properties and functions that operate on Values.
  8. Perspectives on Bindings describes how we make sure that User roles with a Perspective on some role R in the same context, have access to the relevant binding of R - recursively.
  9. Contextualizing Perspectives relies on a powerful abstraction mechanism called aspects. An aspect is a Context that may be added to another Context, which we call a specialiser of the aspect. However, Actions and queries taken from an Aspect have to be contextualised for each specialiser.
  10. Sync subnetworks as a consequence of a new binding
  11. Base Architecture of Perspectives. A high level overview of the functional components of Perspectives and functional and non-functional requirements for the connections between them.

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 depends on version V2.1.1. Versions above V2.3.0 prohibit creating admin users through the HTTP API, while the current version of the PDR relies on that for quick setup and testing.

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