Version v0.3.0 corresponds to the fifth milestone in the project as supported by NLnet. This requires some explanation, as it is the fourth release since the beginning of the project on November 1 2019.
The original release plan gives the following list:
However, we've reordered the milestones by moving 4 behind 6. As a consequence, the current release, while being the fourth, was planned as number 5.
Moreover we've rearranged some of the activities of milestones 5 and 6, moving some from one to the other. These are the new descriptions:
5. Data Exchange I The PDR now compiles all local changes into Deltas, gathered in a Transaction. Transactions are specialised per user according to the model. User accounts can be setup routinely, multiple accounts can be set up on a single node. A Couchdb-based channel for communication is set up, awaiting acceptation from the peer. Transactions are written into the destination channels.
6. Data Exchange II A user can prepare an invitation to connect and grab it from the screen (e.g. to email it to a peer). A user can accept an invitation to connect by dropping it into his InPlace program. Data will then begin to flow. Incoming transactions are processed, Deltas are applied to local state and are checked against the model. A simple app will demonstrate the data-exchange between two peers. It will also demonstrate the effectiveness of the model check.
To wrap up: this fourth release is described by "5. Data Exchange I" above.
The programmatic changes in this release can be grouped in five categories. Most involve synchronisation, the process that automatically moves data between PDR installations to ensure each user has access to information as modelled.
a. The previous release saw inverted queries as a mechanism to trigger bot rules. This same mechanism is now used to compute the peers that a Delta should be sent to.
b. Context- and role serialisation in the form of Deltas. Originally the design of the PDR attributed contexts (and roles) serialised as JSON as the preferred form of distributing new instances. However, for each user involved in a context, a specialised version of such a context must be computed according to his Perspective. It turns out that it is better to serialise a context or role in terms of a set of Deltas and re-use the existing mechanism for simple updates.
a. As the number of mechanisms to ensure this semantics has grown over the project, we felt the need to create an overview. The design document Overview of state change mechanisms lists the five main administrative responsibilities and describes them in some detail: Persistence, Rule Triggering, Query Updating, Synchronisation and Current User Computation.
b. Using this overview as a guideline, a thorough quality improvement was carried out throughout the code base.
c. Major part of this was a redesign of the Functional Reactive Pattern for client programs. Clients register callbacks to be informed of updates to query results previously requested. A change like deleting a context brings with it a host of updates to queries about the contents of that context, but clients are no longer interested in them. Worse, a system like React actually throws errors if state of 'unmounted components' is updated. In other words, even though declarative state is order-independent, updating such state is very order sensitive!
Accounts and Authentication. Up till now, the PDR started with default credentials for a default user. The current release sees a change in that a single PDR installation can serve various end users (these users share a Couchdb installation but nothing else). This work involved processes like creating accounts programmatically, storing (local) authentication details, authentication, conditionally starting the PDR, and a log-in screen.
Distributing Deltas. Deltas come in Transactions. Each Transaction is specialised for a particular user, selecting relevant Deltas. Then, to distribute the Transaction, it is written in a channel database_. This is a local database dedicated to communication between two users.
Miscellaneous. A number of quality improvements have been carried out, such as handling couchdb document versions. Two relevant new functionalities are:
a. Retrieving property values in the role graph. As roles can be bound to other roles, a directed role graph is formed. Starting from any role, all 'downstream' properties can be accessed. This mechanism is now implemented, according the Abstract Data definition of roles.
b. Perspectives has a directly indexed data model. There are a few starting points, such as the users' own System instance. However, at times it is very useful to be able to retrieve instances of a particular role type. For this, a couchdb query mechanism was created, allowing us to implement a new function in the query language.
Various documents have been updated and two new design documents have been added:
The system model (model:System) has been substantially enlarged, now including a case for a Channel, a Model and an Aspect called NamedContext.
A new model and screens have been created: model:SimpleChat. This provides a list of Chats, the functionality to create and delete chats, and a very simple Chat window featuring a way to invite a (known) peer and two text boxes in which the participants can enter and edit text. This mainly serves as a testing device, allowing us to create and test Deltas. In a later release it will be extended to a more conventional Chat program (showing history etc).
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.