Skip to content

Commit 37cf68b

Browse files
authored
chore: clarify event/domain scoping, lifecycle (#248)
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]>
1 parent 57829b0 commit 37cf68b

File tree

2 files changed

+17
-2
lines changed

2 files changed

+17
-2
lines changed

specification/glossary.md

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -28,6 +28,7 @@ This document defines some terms that are used across this specification.
2828
- [Evaluation API](#evaluation-api)
2929
- [Flag Management System](#flag-management-system)
3030
- [Provider](#provider)
31+
- [Provider Lifecycle](#provider-lifecycle)
3132
- [Domain](#domain)
3233
- [Integration](#integration)
3334
- [Evaluation Context](#evaluation-context)
@@ -109,9 +110,13 @@ A source-of-truth for flag values and rules. Flag management systems may include
109110

110111
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.
111112

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+
112117
### Domain
113118

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).
115120

116121
### Integration
117122

specification/sections/05-events.md

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,11 @@ graph
2222
C -->|run handlers| CH(Client event handlers)
2323
```
2424

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.
27+
28+
see: [domain](../glossary.md#domain)
29+
2530
### 5.1. Provider events
2631

2732
#### Requirement 5.1.1
@@ -44,13 +49,17 @@ see: [provider event types](../types.md#provider-events), [`event details`](../t
4449

4550
> When a `provider` signals the occurrence of a particular `event`, the associated `client` and `API` event handlers **MUST** run.
4651
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+
4755
see: [provider event types](./../types.md#provider-events) and [event handlers](#52-event-handlers).
4856

4957
#### Requirement 5.1.3
5058

5159
> When a `provider` signals the occurrence of a particular `event`, event handlers on clients which are not associated with that provider **MUST NOT** run.
5260
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.
5463

5564
see [setting a provider](./01-flag-evaluation.md#setting-a-provider), [domain](../glossary.md#domain) for details.
5665

@@ -130,6 +139,7 @@ This means that the order of provider configuration and event handler addition i
130139
### Event handlers and initialization
131140

132141
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).
133143
_Application authors_ and _application integrators_ use these events to wait for proper initialization of the provider and to do basic monitoring and error handling.
134144

135145
#### Requirement 5.3.1

0 commit comments

Comments
 (0)