15.2. In depth treatment of synchronisation
Consider a context with several thing roles and a couple of user roles. Now assume those user roles have exactly the same perspectives. Anytime one of the peers makes a change, the same transactions (PDR’s exchange transactions that consists of deltas, the elementary changes to structural elements such as contexts and roles) are sent by his PDR to all his peers. This is the base case for synchronisation.
But user roles are defined by their perspectives, so, really, our context has but a single user role. This is a degenerate case indeed: a context with a single user type could be served from a single store, as all participants have access to exactly the same information.
This may not be obvious at first sight, as roles might have different fillers or properties. Perspectives may be valid in some states only, where state can be defined in terms of fillers, but we explicitly stated that all perspectives were equal. Roles might have different properties, but because all user roles have the same perspectives, these properties evidently play no role in them.
Obviously, the general case is more complicated. It turns out that there are two important ways in which contexts differ when it comes to synchronisation:
-
By having user roles have different perspectives on the non-user roles;
-
By having user roles have different perspectives on other user roles.