Release per September 28, 2020: v0.7.0

Version v0.6.0 corresponds to the ninth milestone in the project as supported by NLnet: the Model Checker. The two main contributions with this release are:

The latter contribution resolves a major Perspectives promise, or, actually, three:

Together with the peer-to-peer distribution that ensures confidentiality, these are the major non-functional aspects of the Perspectives Distributed Runtime. A demonstration of this can be found at the Perspect IT blog

Major changes

  1. Delta signing. See Booting a Domain and Who Authors. A PDR installation accumulates additions and changes to the collection of contexts and roles within scope of its end user. These come in the form of deltas. Deltas are cryptographically signed and include the subject role in which the user (or his bot) responsible for the addition or change, acted. There are three sources of data: the end user, his bot, and model files. All sources are covered. For the end user, this implies that all API calls now require the subject role as a parameter.
  2. Invitations are now transactions. Prior to version v0.7.0 an invitation file was a Json format constructed for ease of use by humans (actually, programmers). However, as each data point needs to be signed, we've changed that to the format used by the PDR to exchange information with other PDR's.
  3. Model compilation. To enable efficient fine grained model checking, models are compiled differently. Each Calculated Role and Property is annotated with inverted queries that trace back to user roles that have a perspective on them. We now annotate the properties that can be accessed through such a perspective with the verbs the user has in their perspective.
  4. Transaction checking. Deltas in incoming transactions are now rejected if the role in which their author performed an assignment operation does not allow such actions.
  5. Creating and deleting contexts. Previously we allowed (through the API and through statements in bot rules) direct context creation. This has been replaced by creating (and deleting) their external roles through context roles, as users only have perspectives on roles. This required implementing a set of operations very characteristic of Perspectives.
  6. Keyboard control of InPlace. The entire application can now be controlled by keyboard.
  7. Refactoring of perspectives-react. All components have been adapted to support keyboard control of the application and to support ARIA labeling where applicable.

Minor changes

  1. boundBy. A new language keyword introduces a means to filter roles by restricting how they are bound.
  2. currentcontext and currentrole. Two new keywords provide anchor points for queries. See currentcontext and currentrole.
  3. Deleting contexts. This functionality existed before but did not cover all cases. Now we can delete both indexed (linked) contexts, and 'free floating' (unlinked) contexts (these contexts are accessed through Database Query Roles).
  4. bots for the Guest role used to fire whether the Guest role was filled or not (the Guest role is by definition a Calculated role). They no longer do so, meaning that the Guest role is silenced as soon as the end user fills some other role in the context.
  5. Database removal. Contexts and roles are now removed on a per-transaction basis, i.e. right at the end of a transaction.
  6. Network failure. Database Query Roles no longer fail when no network is available.

Documentation

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

  1. Booting a Domain. When a user adds a Model to his PDR, he automatically adds some context- and role instances, too. Collectively, we call them the base model instances. This text shows how these instances are contributed to authors.
  2. Who Authors. Whenever a change is made to the data in the Perspectives Universe, we should record the role in which the user acted. This text discusses how to determine that role.
  3. Creating and Deleting Contexts. What user roles have the right to create a context instance? Perspectives grants its users their powers exclusively through perspectives on roles. In order to dole out rights for creating contexts, we introduce a verb specifically for creating contexts, to be bound to a context role in an embedding context: CreateAndBindContext.
  4. currentcontext and currentrole. The Perspectives Language consists partly of expressions. An expression traces a path through the network of roles and contexts, possibly ending in a property’s values. Obviously these paths must start somewhere! However, sometimes it is necessary to return, in the middle of a calculation, to the base of a calculation in order to retrieve some value from it. To enable the modeller to do so we introduce two new keywords: currentcontext and currentrole.
  5. The Case for Database Query Roles. One of the design goals for Perspectives is that all context- and role instances must be reachable. This can be attained by direct indexing (e.g. a role is directly linked to its context), alternatively by deploying an indexed name, or finally by a database query that retrieves instances of a particular type. The text explains the use cases for such Database Query Roles.
  6. Keyboard alternative to drag and drop. The InPlace GUI relies heavily on the notion of inserting a role card into a role slot, to create a binding (or to create a new role filled with another). Mouse-mediated drag and drop is a very natural way to perform this action, but is unavailable to some desktop users and obviously not available on mobile or tablet. We solve the problem by adding another method of role binding, that relies entirely on the keyboard on the desktop.

Documents that have been updated:

  1. Module imports for InPlace
  2. Assignment
  3. Building a release
  4. Rules
  5. Implementing the Functional Reactive Pattern