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
In #268, the BaseNodeRunner is refactored to allow for generic extensions. These are strongly typed instances of the BaseNodeExtension trait that removes the ad-hoc extensions installation contained inside the BaseNodeRunner. Instead, extension installation is hoisted to the binary entrypoint to allow the node to be configured programmatically. By using explicit extension installation at the consumer level, the node becomes more configurable and avoids silent, unknown extension behavior.
Tangentially, #268 moves the FlashblocksCell into the BaseNodeConfig. Previously, it had been instantiated and passed into both the FlasblocksCanonExtension and the BaseRpcExtension through the constructor method. No longer. The FlashblocksCell is now placed in the BaseNodeConfig. Since the BaseNodeExtension creates the extension using the BaseNodeConfig, the extension constructor can just clone that OnceCell from the BaseNodeConfig.
Description
Note
TL;DR Background: #268 made extensions generic, moving the FlashblocksCell type into the config so it can be cloned when constructing the FlasblocksCanonExtension and BaseRpcExtension extensions.
This issue is to figure out how to make this approach more extensible. As new extensions are added in the future, we want to avoid type stuffing, where the BaseNodeConfig continuously grows.
One option is to just generic parameters - T::Config - for the extension install. That is, the config type is defined by the extension and the install method looks like: runner.install_ext::<T>(T::Config)?;. This way, the consumer (node builder) is forced to instantiate the FlashblocksCell and then pass it in as a parameter to the extensions that require it. The downside to this approach is expanding the node entrypoint - main.rs needs to perform this extension install argument wiring as they increase in complexity.
Background
In #268, the
BaseNodeRunneris refactored to allow for generic extensions. These are strongly typed instances of theBaseNodeExtensiontrait that removes the ad-hoc extensions installation contained inside theBaseNodeRunner. Instead, extension installation is hoisted to the binary entrypoint to allow the node to be configured programmatically. By using explicit extension installation at the consumer level, the node becomes more configurable and avoids silent, unknown extension behavior.Tangentially, #268 moves the
FlashblocksCellinto theBaseNodeConfig. Previously, it had been instantiated and passed into both theFlasblocksCanonExtensionand theBaseRpcExtensionthrough the constructor method. No longer. TheFlashblocksCellis now placed in theBaseNodeConfig. Since theBaseNodeExtensioncreates the extension using theBaseNodeConfig, the extension constructor can just clone thatOnceCellfrom theBaseNodeConfig.Description
Note
TL;DR Background: #268 made extensions generic, moving the
FlashblocksCelltype into the config so it can be cloned when constructing theFlasblocksCanonExtensionandBaseRpcExtensionextensions.This issue is to figure out how to make this approach more extensible. As new extensions are added in the future, we want to avoid type stuffing, where the
BaseNodeConfigcontinuously grows.One option is to just generic parameters -
T::Config- for the extension install. That is, the config type is defined by the extension and the install method looks like:runner.install_ext::<T>(T::Config)?;. This way, the consumer (node builder) is forced to instantiate theFlashblocksCelland then pass it in as a parameter to the extensions that require it. The downside to this approach is expanding the node entrypoint -main.rsneeds to perform this extension install argument wiring as they increase in complexity.