4.2. Client requests
A client sends requests to the PDR. The core keeps the client up to date with changes to the underlying network by a mechanism of callbacks. In short: the client sends a callback along with its request and the PDR sends (new) results by calling it with those results.
In essence, the API of the PDR allows the client to request any of the five types of query step. Each step must be complete with arguments: for example, the client should say which role instance it wants to see the binding of; similarly, it should additionally say what type of role binders it is interested in (i.e. the type of the role instances that bind a given instance).
It follows that the client always requests nodes that are direct neighbours of another node. This means that the order in which a client requests nodes, depends on the underlying structure, as the client has no means of knowing the identity of a node before it has received that node from the PDR.
With the exception of Named Nodes. These are nodes that have a universal readable name besides their GUID-based identifiers. A modeler may use a Node Name (mostly context instance names) in a query; a screen programmer can start a data container with such a node.
4.2.1. Consequence of request order
Consider the situation in which a client (typically, a React screen) has requested a context, some roles in it and some of their properties. Now that context is deleted, let’s say by another user. What requests does the PDR recalculate?
Let’s take the React screen as an example. It is built, tree-like, from nested data containers that hold, as terminal leaves, simple display components. A role data container will be nested inside a context data container. Now if the context container disappears (is unmounted), the client is no longer interested in updates for requests that originate from the data containers inside it. This is because it will scrap the entire context data container with all that is inside. As a matter of fact, it is even an error to try to update the data in unmounted components.
How does the PDR prevent updates to updated components? How does it ensure that other requests that are affected by this change, are updated?
4.2.2. How to visit a context
There are but three ways to enter a context, or, in other words, queries can alight in just three ways on the nodes that make up a context in the graph from outside that context.
Figure 2. All ways to visit a context. Red parts will disappear when the context is removed.
As the figure shows, first contact with a context is always through a role instance; and this is either through the binding query step or the binder <RoleType> querystep.
4.2.3. Deleting a context
Figure 2 illustrates clearly what client requests should be recomputed if a context disappears. These are requests (green lines) from roles that will remain (in blue) to roles that will disappear (in red).
All other requests involving parts of the context that will disappear, must be ignored. Without exception they are requests that originate in parts that will have gone after the context has been removed; moreover, they will be context, role <RoleType> or property <PropertyType> requests.
By updating the former types of requests and ignoring the latter types, the PDR addresses both questions. All requests that need be updated are, in fact, updated; and no requests are updated that the client is no longer interested in.