Release per November 25, 2020: v0.8.0

Version v0.8.0 corresponds to the seventh milestone in the project as supported by NLnet: Data exchange: peer-to-peer exchange. This is the last of the nine milestones agreed upon in the Memorandum of Understanding for this project. As with the last two releases, this one is quite large as many issues had to be resolved before the goal set for this release could be reached; issues we had expected that only had to be addressed later. To plan innovative software development for a period as long as a year remains a haphazardous undertaking!

Major changes

• A new transport layer. Since version v0.5.0, two InPlace installations have been able to synchronise, as long as they could reach each others Couchdb through HTTP. In this release we have added a new Transport layer that makes use of AMQP. While the PDR (and with it InPlace) still is distributed on the application level (meaning there is no central repository of information exchanged in the co-operation), it now uses a 'postal service' that uses central hubs, much like ordinary email. We've set up a RabbitMQ server where an end user can have an account (currently on invitation base only). As a consequence, two InPlace installations anywhere in the world can synchronise as long as they know each others logical address.
• Keyboard control of InPlace. InPlace, the graphical front end for the PDR, relies heavily on drag and drop. A role is represented by a draggable card and dropping it amounts to creating a binding. All components that involve cards are now keyboard-ready. That is, one can manipulate cards with just the keyboard.
• Accessibility. Implementation of the recommendations in the report by the Accessibility Foundation. See the landing page for the project for references.
• A component FileDropZone. Drop a file, provide a handler. To operate with keyboard, select and press space.
• A RoleTable component. An important building block for the graphical user interfaces, this component creates, in one go, a table for a multi-role, complete with keyboard navigation, role creation and a column that holds a card representation of the role that can be dragged and dropped.
• Setting properties in the role chain. Previously, a property value was manipulated on directly on the role instance that was provided to the assignment operators. This is inadequate when that instance is the root of a chain of bindings, where not the root but one of the instances in the chain can actually bear that property type.
• Bot rules now apply to single objects. A bot executes rules for a user. Such a rule applies to a context. However, it also applies to the object role of a Perspective. In the body of a rule the object variable is now bound to a single instance of that role (it used to be bound to all object instances). This gives us finer grained control over state modifications and discharges us from the need to create a Calculated Role if we want to apply the rule to just a subset of the Perspectives' object.
• Complete refactoring of serialising a context for a peer. The (now deprecated) algorithm only handled explicitly represented roles and properties. That is, on serialising a context for a user role X, any calculated roles or properties that X has a perspective on, were not included. This was a significant limitation, as queries connect remote contexts over paths and so enhance the scope of a user considerably (that what he can 'see'). The new algorithm is based on a new query interpreter mechanism that logs all visited nodes (contexts and roles) that lead to end results and then includes all deltas that construct those nodes into the serialisation.
• Dropzone split into two. We now have a DropZone (for roles) that handles the case in which a role exists, and one in which a role should be constructed.
• Refactoring of several React data components. We rationalised the distribution of the various manipulation functions (add a binding, remove a binding) over components, making them more orthogonal. The react Context PSRolBinding has disappeared, being included in existing contexts.

Minor changes

• Better error message when a property type cannot be found on a role type on requesting a property value through the API (GetProperty).
• The UI can ask the PDR for the user role played by the system user in a context that holds a specific role. Usually, this mechanism is used to retrieve the screen created for the perspective of this user role. And more often than not, the role that it all starts with is a context role. If so, the current implementation treats it as if its binding was sent in.
• Removing a role failed under certain conditions in the cascade delete of bound contexts. Fixed.
• The Screen component failed on contextRoles. Fixed by detecting whether the role instance is an external role or not.
• Fixed bug in getting property values from specialised roles.
• The screen component now displays a warning and a back button if the end user tries to open a context that he has no role in.
• CalculatedRole and CalculatedProperty definitions are now saved in the DomeinFile in cache immediately after compilation, mitigating the risk of referencing them before they are compiled.
• The binder step was represented as non-functional in the query description compiler. However, we've recently introduced a new default, to wit that a role may bind a particular role instance only once - effectively making the reverse operation (binder) functional.

Documentation

New documents have been added:

1. Become. A new action verb for a very common situation, where a user role fills another user role in a freshly created embedded context. For example: one of the members of a meeting becomes the chair of a new committee. The verb leads to a new assignment operator that creates a new context role, a new context, a new user role in it and fills it with the original user role in one go.
2. Multiple databases, interfaces and transaction handling points. Architectural aspects of various compositions of the UI, a database and the PDR.
3. A Transport layer for the PDR. Motivation of the architectural design choice to use AMQP until a really good P2P message protocol is available.
4. Cascade delete. Design for clearing inaccessible roles and contexts from the database.
5. Stomp for InPlace. Technical details on how the STOMP protocol is used to access an AMQP broker service.
6. 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.

Updated documents:

• Query Inversion
• Assignment
• The case for an object variable in rules
• Rules
• Building a release