12.4.6. Multiple devices
Useful as multiple UI’s can be, in order to be able to use MyContexts seamlessly on both laptops and mobiles, for example, another setup is required. One such setup would be to run a THP as a service and just run the clients locally. While this is perfectly defendable, scaling the service might become a challenge as a generic THP is quite resource-hungry.
Another setup would be to run UI and THP locally but store data in a place that can be accessed from multiple devices. Again, a commercial service on the internet might be a solution; but so might be a home server.
12.4.6.1. Database subscription service required
However, this introduces another functional requirement for the database (and some extra handling by the THP). This is because MyContexts operates according to a what you see is what you have principle. To be more precise: the contexts and roles visible on screen are guaranteed to be a faithful representation of the state of that part of the Perspectives Universe.
Now consider the situation where an end user enters, for example, an utterance in a chat, using his mobile phone. Were his laptop to show the same chat, his words would not appear automatically there, too. This is because the update of the GUI is driven by transactions. Let’s delve into this a little deeper.
When chatting on his mobile, the end user clearly wants to receive his answers there – not on his laptop. We have seen above that we may specify different THP’s for various user roles, but in the end a transaction is sent to just one such THP. So the mobile should receive the chat-related transactions while the end user is on it – and that leaves the laptop in the dark.
We can remedy that situation by requiring the database to offer a subscription service that provides the subscribing THP with a stream of modified, new and deleted entities. On receiving such a changed entity, a THP would compare the arriving entity with its existing version, work out the difference in terms of new deltas and then check its dependency administration to see if one of its GUI clients has subscribed to a query for which the delta is an assumption.
So, to return to our example setup, the laptop would subscribe to the database and be informed of new utterances. As its GUI client has an active query regarding these utterances, the PDR would re-run the query as soon as the database sends a new one.
12.4.6.2. What is the active THP?
Notice that a new notion has crept into our discussion: that of a THP that can be the intended receiver of transactions or not, based on the device the end user is handling. This is a subtle notion and its implementation is not trivial. For what is ‘handling’? When two devices are simultaneously active, how should peers know where to send a transaction?
There are no easy answers here. For the time being, we will satisfy ourself by a simple priority list, combined with a notion of being available or not. Each peer will come to send transactions to the same THP, based on this approach.
Notice that while the priority list is stable and can suitable represented in Perspectives itself in terms of contexts and roles, this is not the case for availability. Preferably the channel we use for sending transactions would handle this issue(see [State and Notification] for a notion of availability that could be useful for this issue).
12.4.6.3. Analysis: why each transaction is handled only once
Could the same transaction be handled by multiple THP’s? Executing a same delta a second time is an idempotent operation, so at first sight it seems harmless to have two THP’s handle the same transaction (but notice that storing the same value twice in a database need not be idempotent!). But changes can trigger bot rules and thereby change the Perspectives Universe again. Care is taken, in the design and implementation of the Perspectives language, to provide a clear and deterministic semantics to these operations. However, having multiple processors carry out the same process, interleaving the results in unpredictable order (due to varying transport times) probably really complicates these issues. And each THP will compile the same transactions and send them on to the relevant peers, where the process might trigger yet more consequences, etc.
For that reason, we will require that just a single THP handles a particular transaction.