Release per June 23, 2023: MyContexts v0.20.0

First of all, we have dropped the name InPlace in favour of MyContexts. This means the application can now be found at https://mycontexts.com.

MyContexts Version v0.20.0 delivers the following milestones in the project Perspectives: Making Models as supported by NLnet:

• Managing Versioned Models (Milestone 2).

It has been some time since the previous release (September 23, 2022). Apart from reasons of less available capacity (personal circumstances), we first spent a month on documentation and then embarked on a major refactoring that took a lot more time than expected. A short explanation is in order. Up till version v0.19.0, all user-created resources were stored just in a local database (either the browsers' IndexedDB or a locally running instance of Couchdb). All resources were, therefore, stored in the same location and we wanted to offer a freedom of choice. Related, but not the same: type descriptions (models) were stored in a single repository (and actually a database in some Couchdb installation). Thus, when a PDR/MyContexts installation encountered an unknown type, it assumed it could find a model with this type in this repository.

We have generalized the way both types of resources are stored:

• we now deploy a different resource identifiction scheme (applied to context- and role instances and to locally stored versions of type descriptions) that allows us to encode, right in a resource's identifier, a clue as to where it should be stored and retrieved. These clues are purely personal; so transactions of deltas refer to 'bare' identifiers, stripped from their storage scheme. This allows us to store resources extremely flexible: from a local database to just about any REST endpoint. Authentication for such endpoints is handled automatically.
• types are now globally resolvable. This means that a PDR, when confronted with an unknown type identifier, can retrieve from that identifier information about the location on the internet where its definition can be found. Accompanying this new scheme for type identifiers is a Perspectives model that allows us to manage Couchdb installations on the internet, maintaining Repositories with Manifests for models. Many Versions for each Manifest may be maintained and the end user can choose what version to deploy locally. This is an extremely important condition for a healthy ecosystem to develop: anyone can now open a repository, publish models, share resources with peers whose installation will then, just in time retrieve the required type definition set.

Public contexts revisited. In version v.0.19.0, public contexts were introduced. Technically these were a forerunner of the more generalised storage scheme that comes with version 0.20.0. In short, it required (or enabled) the modeller to store resources in a specific location. This approach, however, turned out to be flawed. It did not incorporate the extreme interrelatedness of context- and role instances. It happened, for example, that a public role was filled with a locally stored one. While working perfectly for the owner of the locally stored filler, the system's semantics would break down for others who visited the public role.

The current version fixes all that. Conceptually the change is simple; technically it turned out to be very involved. The idea is that a public perspective on a context is just that: the perspective of some role that we would like to be public. That is, anyone should be able to take on that role. This we can realise by storing the resources in a publicly accessible place - in other words, by publishing them. A modeller can now include a user role that he declares public at a certain location. The (versions of) the contexts and roles that this user role - usually, but not necessarily called Visitor - is allowed to see according to his perspective on the context, are stored in that location. In principle this would require a PDR 'running at that location'. However, we want Perspectives to rely as little as possible on processes hosted at a server. So instead we have arranged that Transactions (Delta's of resources) for a public role _are interpreted by the PDR instead of actually sending it somewhere. This works beautifully, as we can take advantage of the entire existing machinery for sharing resources - putting it to work for this new functionality of public contexts.

Major changes

• Storage schemes. It is now possible to store context- and role instances of a given type in a location of choice.
• Globally resolvable types. The PDR now performs just in time loading for any type it encounters. Moreover, models (or rather their compiled counterparts, so called DomeinFiles) can be stored anywhere on the web. This is governed by model://perspectives.domains#CouchdbManagement.
• Publish contexts by declaring a public user role. The perspective of such a role is available at a location of choice.

Minor changes

A selection of the bigger minor changes... in fact we have 161 commits relating to some 45+ minor items in the PDR alone.

• Just in time model loading using coroutines. Loading a model is a high-level function in terms of the hierarchy of modules that make up the PDR. However, looking up a type definition is a low-level function (it happens, for example, immediately after reading in a resource from disk). Consequently, when we encounter an unknown type and want to call the just-in-time model loader, this is flagged down by the Purescript compiler because it introduces cycles in the module graph. We have solved this by forking a thread (or fiber as they are called in Purescript) right at startup of the PDR, that functions as a co-routine whose single purpose is to receive requests to add a model to the local installation.
• Retired the Context Role Language (CLR) Parser. The Perspectives Language (model texts are stored as .arc files) allows us to describe types. However, a model also requires some instances in order to function in a PDR installation. Previous to the current version this was achieved by combining an .arc file with a .crl file. Such files contain descriptions of instances and were written in an entirely different language (the CLR language can be seen as a more primitive version of PL). However, we now have a sufficient set of assignment and creation statements to do away with CLR. Moreover, on installing a model locally, we create its model context and in the on entry of its base state we can create all instances we like.
• Fixed retrieving calculated properties. A calculated property is defined as a query on the network of context- and role instances. The semantics of roles is such that all properties defined on a role and its fillers are immediately available on that role instance (we speak of a role telescope; all properties should be accessible at the top). However, the path set out by a calculated property is written on the assumption that it starts at an instance of a particular type. The implementation did not take this into account.
• Catching recursive queries in the compiler. A calculated property or role consists of a query. A modeller can inadvertently create a cyclic query path. Prior to this improvement this caused an infinite loop in the type checking system.
• Read- and write databases. Couchdb has a system of roles and authorizations that does not entirely fit Perspectives' needs. It is not possible to model read access to a database while denying write access. We now handle this by having two physical databases for a single conceptual one, where Couchdb membership of the write database allows members to write, while Apache rules prevent non-members from sending destructive HTTP verbs to the read database.
• Systematic model dependencies. All dependencies in code on type names defined in PL models are collected in a single file as constants that are used throughout the code instead of static strings.
• i18next based translation. All strings in code that make it to the user interface are now run through i18next, allowing for translation. We currently provide English and Dutch. NOTE: this does not yet allow for model translation.
• PerspectivesProxy is now promise based where possible. Call to the API of the PDR come in three types: assignments that change Perspectives state (and have no interesting functional result), one-time only requests for information (usually resources) and subscriptions to queries. The middle category is now implemented as Javascript Promises.
• PerspectivesFile component. This is a new, overloaded React component that allows us to handle files in the user interface. Is accompanied by a File Range type in the Perspectives Language. Displays images when the mime type is appropriate. Displays syntax colored code for the mime type "text/arc". Will in the near future support Markdown.

Updated documents:

Technical documentation is now only published at https://mycontexts.com/techdoc/.