You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding some additional non-normative text to clarify a few things at the
prompt of @federicobond .
The meaning and justification should be self-evident, and if it's not I
did a bad job. 😅
---------
Signed-off-by: Todd Baert <[email protected]>
@@ -109,9 +110,13 @@ A source-of-truth for flag values and rules. Flag management systems may include
109
110
110
111
An SDK-compliant implementation which resolves flag values from a particular flag management system, allowing the use of the [Evaluation API](./sections/01-flag-evaluation.md#13-flag-evaluation) as an abstraction for the system in question.
111
112
113
+
### Provider Lifecycle
114
+
115
+
The possible states and transitions of a provider over the course of its usage, as defined by the [provider interface](./sections/02-providers.md).
116
+
112
117
### Domain
113
118
114
-
An identifier which logically binds clients with providers, allowing for multiple providers to be used simultaneously within a single application.
119
+
An identifier which logically binds clients with providers, allowing for multiple providers to be used simultaneously within a single application. Domain binding is dynamic; it may change over the course of an application's lifetime (ie: a client associated to the default provider via an unbound domain will be bound to a new provider if a provider is subsequently assigned to that domain).
Copy file name to clipboardExpand all lines: specification/sections/05-events.md
+11-1Lines changed: 11 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,6 +22,11 @@ graph
22
22
C -->|run handlers| CH(Client event handlers)
23
23
```
24
24
25
+
The `domain` of a provider constitutes a logical scope for events.
26
+
Clients associated to a particular provider through a `domain`, run event handlers only when that provider emits events, or one of its lifecycle functions terminates.
> When a `provider` signals the occurrence of a particular `event`, the associated `client` and `API` event handlers **MUST** run.
46
51
52
+
Client event handlers respect the dynamic binding of clients to providers via `domains`.
53
+
Client event handlers run when a lifecycle function terminates on the associated provider, or the associated provider emits an event.
54
+
47
55
see: [provider event types](./../types.md#provider-events) and [event handlers](#52-event-handlers).
48
56
49
57
#### Requirement 5.1.3
50
58
51
59
> When a `provider` signals the occurrence of a particular `event`, event handlers on clients which are not associated with that provider **MUST NOT** run.
52
60
53
-
Providers bound to a `domain` constitute their own "events scope".
61
+
Client event handlers respect the dynamic binding of clients to providers via `domains`.
62
+
Client event handlers do not run when a lifecycle function terminates on an unassociated provider, or an unassociated provider emits an event.
54
63
55
64
see [setting a provider](./01-flag-evaluation.md#setting-a-provider), [domain](../glossary.md#domain) for details.
56
65
@@ -130,6 +139,7 @@ This means that the order of provider configuration and event handler addition i
130
139
### Event handlers and initialization
131
140
132
141
Though providers themselves need not implement events, the `flag evaluation API` uses events to convey relevant state changes during configuration and initialization.
142
+
Implementations automatically emit `PROVIDER_READY` or `PROVIDER_ERROR` events depending on the outcome of the `initialize` function, if the provider has implemented one (if none is implemented, `PROVIDER_READY` runs unconditionally).
133
143
_Application authors_ and _application integrators_ use these events to wait for proper initialization of the provider and to do basic monitoring and error handling.
0 commit comments