... | @@ -16,7 +16,7 @@ Kea hook is a shared library. Each hook is composed of the following symbols: |
... | @@ -16,7 +16,7 @@ Kea hook is a shared library. Each hook is composed of the following symbols: |
|
Additionally, the hook may contain one or more "callout". The "callout" is a function that the Kea calls out.
|
|
Additionally, the hook may contain one or more "callout". The "callout" is a function that the Kea calls out.
|
|
Each callout function has the same signature. It accepts a reference to a `CalloutHandle` object and returns an integer. A value of 0 indicates success; anything else signifies an error. The status return does not affect server processing; the only difference between a success and error code is that if the latter is returned, the server will log an error, specifying both the library and hook that generated it. Effectively the return status provides a quick way for a callout to log error information to the Kea logging system.
|
|
Each callout function has the same signature. It accepts a reference to a `CalloutHandle` object and returns an integer. A value of 0 indicates success; anything else signifies an error. The status return does not affect server processing; the only difference between a success and error code is that if the latter is returned, the server will log an error, specifying both the library and hook that generated it. Effectively the return status provides a quick way for a callout to log error information to the Kea logging system.
|
|
|
|
|
|
The `CalloutHandle` object provides two methods to get and set the arguments passed to the callout. These methods are called (naturally enough) getArgument and setArgument.
|
|
The `CalloutHandle` object provides two methods to get and set the arguments passed to the callout. These methods are called (naturally enough) `getArgument` and `setArgument`.
|
|
|
|
|
|
The hook libraries provide their own log messages and logger instances.
|
|
The hook libraries provide their own log messages and logger instances.
|
|
|
|
|
... | @@ -28,3 +28,13 @@ The hooks are independent of the main Kea codebase. There is a single common mod |
... | @@ -28,3 +28,13 @@ The hooks are independent of the main Kea codebase. There is a single common mod |
|
|
|
|
|
The main advantage of the Kea design is a separation between the main codebase and hooks. It allows writing hook code without knowledge about the Kea itself. Kea also separates the log messages that making any troubleshooting easier. Another beneficial feature is the easy and bidirectional data exchange between core and hook.
|
|
The main advantage of the Kea design is a separation between the main codebase and hooks. It allows writing hook code without knowledge about the Kea itself. Kea also separates the log messages that making any troubleshooting easier. Another beneficial feature is the easy and bidirectional data exchange between core and hook.
|
|
A significant disadvantage is weak typing. The compiler cannot test the correctness of the hook signatures because the hook name is stored as a string and the arguments are dynamically retrieved and cast. It is tough to detect if something changed in a complex structure used as an argument.
|
|
A significant disadvantage is weak typing. The compiler cannot test the correctness of the hook signatures because the hook name is stored as a string and the arguments are dynamically retrieved and cast. It is tough to detect if something changed in a complex structure used as an argument.
|
|
|
|
|
|
|
|
## Go hooks - technical basis
|
|
|
|
|
|
|
|
There are three different ways to implement hooks in Golang.
|
|
|
|
|
|
|
|
1. Use [plugin](https://pkg.go.dev/plugin) built-in module
|
|
|
|
2. Use [go-plugin](https://github.com/hashicorp/go-plugin) library
|
|
|
|
3. Implement them as C extensions
|
|
|
|
|
|
|
|
We discussed a proper approach during a meeting in Berlin and decided to use the `plugin` module. It is a pretty new Go feature, but it seems that this method should be most similar to the Kea hook solution and cover all expected use cases. We are only unsure how to handle the UI with a hook based on the `plugin` module. We want to start with backend-only hooks and re-think this problem later. We don't exclude the possibility of implementing the hooks with GUI as separate services using `go-plugin` and RPC connection. We decided to avoid the third approach because we think the hooks should be written in Go if possible. |