... | @@ -291,7 +291,7 @@ The handling of hook communication will be the responsibility of the `Hook Execu |
... | @@ -291,7 +291,7 @@ The handling of hook communication will be the responsibility of the `Hook Execu |
|
|
|
|
|
We have a special `context.Context` structure in Go. It is a bag for variety, unstructured data. We can assume that each callout point will accept the context object. The same context instance will be passed to each hook sequentially. It allows hook's authors to internally manage the structure of the context and data exchange rules. The core will be only responsible for creating the context object and will know nothing about its content.
|
|
We have a special `context.Context` structure in Go. It is a bag for variety, unstructured data. We can assume that each callout point will accept the context object. The same context instance will be passed to each hook sequentially. It allows hook's authors to internally manage the structure of the context and data exchange rules. The core will be only responsible for creating the context object and will know nothing about its content.
|
|
|
|
|
|
### Exchange data using callout parameters
|
|
### Exchange data using callout signature
|
|
|
|
|
|
In this case, the data sharing is controlled by the core. It means that the core knows the data meaning and may interrupt the hook execution or modify the data between calling the callout points.
|
|
In this case, the data sharing is controlled by the core. It means that the core knows the data meaning and may interrupt the hook execution or modify the data between calling the callout points.
|
|
|
|
|
... | @@ -301,7 +301,7 @@ There are two approaches to implementation. The first uses a single mutable obje |
... | @@ -301,7 +301,7 @@ There are two approaches to implementation. The first uses a single mutable obje |
|
|
|
|
|
Using both exchange solutions in a single callout point may be beneficial. The context may be used to share the data, and the particular callout point argument/output may be used to control the execution.
|
|
Using both exchange solutions in a single callout point may be beneficial. The context may be used to share the data, and the particular callout point argument/output may be used to control the execution.
|
|
|
|
|
|
The data structure will be maintained internally by the hooks, but there will be a dedicated output enum or a controller object known for the core. This entry will be used to interrupt the execution or control the hook order.
|
|
The data structure will be maintained internally by the hooks, but there will be a dedicated output enum or a controller object known for the core. This entry will be used to interrupt the execution.
|
|
|
|
|
|
It is assumed that the communication between hooks and core is done only in a few cases. It's possible to implement a generic solution applicable to many callout points.
|
|
It is assumed that the communication between hooks and core is done only in a few cases. It's possible to implement a generic solution applicable to many callout points.
|
|
|
|
|
... | @@ -317,7 +317,21 @@ In the second case, the hook executor always continues the hook loop to the end. |
... | @@ -317,7 +317,21 @@ In the second case, the hook executor always continues the hook loop to the end. |
|
|
|
|
|
### Execution order
|
|
### Execution order
|
|
|
|
|
|
### Comparison
|
|
We decided not to use the configuration file with a list of hooks to load (as it works in Kea). The Stork will load all hooks from the specific directory dynamically. It should be convenient because new hooks will be added by copying and pasting them. The main disadvantage of this solution is missing the possibility to specify the order of hook execution.
|
|
|
|
|
|
|
|
The hooks may be loaded in a predictable order by sorting them by name. A user may add the numerical prefixes (`00_`, `01_`, `02_`, etc.) to configure the order.
|
|
|
|
|
|
|
|
In exceptional cases, the hook executor may use a custom order for some specific callout points.
|
|
|
|
|
|
|
|
### Comparison & summary
|
|
|
|
|
|
|
|
| Exchange method | Does the core understand the data? | How is interruption supported? |
|
|
|
|
| :-------------- | :-: | -----------------: |
|
|
|
|
| Using context | NO | Internally by hook |
|
|
|
|
| Using signature | YES | Externally by core |
|
|
|
|
| Using both | NO | Externally by core |
|
|
|
|
|
|
|
|
In my opinion, we need to choose the exchange method for each callout point separately. We should assume as a good practice to always pass the context. We can prepare a generic controller to interrupt the hook loop used in callout points where the interruption is expected.
|
|
|
|
|
|
## Steps to implement hook
|
|
## Steps to implement hook
|
|
|
|
|
... | | ... | |