...
- At the highest prioirty level (Priority 1), Zone[1] can shut off all outbound data record changes to Zone[2]. At the lowest priority level (Prioirty 5), Zone[1] can shut off sharing a single attribute on a single adaptor (that it owns) to Zone[2].
- Sharing precedence is based on the priority e.g. If Zone[1] has turned off access to Zone[2] (Priority 1), then all other sharing actions are null.
- Permissions for each element are based on REST operations GET, PATCH, POST and DELETE. An additional operation is added for PUSH, where a zone allows another zone to receive real-time changes. However, it may be determined that GET will include PUSH.
Inbound ACLs
Background
Generally, metadata considerations revolve around (but are not limited to) inbound data in a federated data domain.
Types of Metadata
Metadata includes granular settings for the following items.
Incoming Filters
A zone or adaptor has the capability of filtering out changes it has acess to.
- "forbid" zone: Don't GET or accept any updates from a zone
- "forbid" adaptor: Don't GET or accept any updates from an adaptor
Classes
Adaptor classes (1, 2, 3): Allows a zone or an adaptor in a zone to set a class level on adaptors that are sharing data with them, where 1 is the highest class level and 3 is the lowest class level. For example, if a GET yields three adaptors with the same domain property, and one adaptor is a class 1 and the others are class 2, then the data from the class 1 adaptor is returned in the GET.
Timestamps
Timestamps: Allows a zone or an adaptor to use a key/map of change timestamps and hashes. For example, if a GET yields two adaptors with the same property and both are the same level, we can take the one with the latest timestamp.
Latency (post pilot)
Latency: Allows a zone or an adaptor to use latency times for changes. If a GET request is issued with a reduced-latency parameter, the request will query only the adaptors that are in PLAY or PLAY_RO (play read only) with the lowest latency times.
