RFC: Implementing a Hooks and Plugins System

[NekoOs]

Abstract

This RFC proposes the introduction of a flexible and secure system for hooks and plugins. The system will allow developers to extend and customize functionality by registering functions (hooks) that can be executed at specific points in the script's lifecycle. Plugins will use these hooks to inject additional logic without modifying the core codebase.

Motivation

The primary motivation for implementing hooks and plugins is to provide a modular and extensible architecture. This will enable developers to add new features, customize existing behavior, and interact with the script’s lifecycle in a controlled manner. By using hooks, the core functionality remains clean and maintainable, while plugins can be developed independently to extend or modify behavior as needed.

Proposal

1. Hooks Implementation:

   • Definition: Hooks are specific points in the lifecycle where custom functions can be executed.
   • Hook Points:
     • pre_init_config: Before the configuration initialization.
     • post_init_config: After the configuration initialization.
     • pre_register_arguments: Before argument registration.
     • post_register_arguments: After argument registration.
     • pre_read_line: Before reading a line from the source script.
     • post_read_line: After reading a line from the source script.
     • pre_import_handling: Before handling an import statement.
     • post_import_handling: After handling an import statement.
     • pre_script_finalization: Before finalizing the script.
     • post_script_finalization: After the script has been finalized.

2. Plugins Integration:

   • Definition: Plugins are external scripts that register functions (hooks) at specific points in the lifecycle.
   • Plugin Structure:
     • Plugins are simple Bash scripts stored in a plugins/ directory.
     • Each plugin can define one or more functions that correspond to the available hooks.
     • Functions are registered automatically when the plugin is loaded, without requiring eval or complex registration logic.

3. Technical Implementation:

   • Hook Registration: Hooks are registered using a centralized function (add_hook), which stores function references in associative arrays.
   • Execution: When a hook point is reached, all registered functions for that hook are executed in the order they were added.
   • Plugin Loading: Plugins are loaded at runtime, and their hook functions are automatically registered. This process ensures that plugins do not interfere with each other and that all hooks are executed as intended.

4. Example Use Case:

   Plugin 1: Custom Configuration Plugin:

   # plugins/custom_plugin.sh
   pre_init_config() {
       echo "Custom Plugin: Adding custom configuration..."
   }
   
   post_init_config() {
       echo "Custom Plugin: Configuration initialized."
   }

   Plugin 2: Additional Configuration Plugin:

   # plugins/another_plugin.sh
   pre_init_config() {
       echo "Another Plugin: Setting additional configuration..."
   }
   
   post_init_config() {
       echo "Another Plugin: Verifying post-configuration."
   }

   Behavior:

   • When the script is executed, both plugins are loaded, and their functions are registered in the corresponding hooks.
   • The lifecycle will execute each hook function in the order they were registered, ensuring that all plugins interact correctly without conflicts.

5. Discussion Points:

   • Hook Granularity: Are the proposed hook points sufficient, or should additional hooks be introduced?
   • Plugin Conflicts: How should conflicts be handled if multiple plugins attempt to register functions for the same hook? Is the order of execution sufficient, or should there be priority levels?
   • Security Considerations: What measures should be taken to ensure that plugins do not introduce security vulnerabilities? Should there be a verification or sandboxing process for plugins?

6. Unresolved Questions:

   • Performance Impact: Will the addition of hooks and plugins have a significant impact on performance? If so, how can this be mitigated?
   • Plugin Configuration: Should plugins be allowed to have their own configuration files or settings, and if so, how should these be managed?

Conclusion

The introduction of a hooks and plugins system will greatly enhance flexibility and extensibility. By allowing developers to inject custom logic at key points in the lifecycle, the script can be adapted to a wide range of use cases without compromising the integrity of the core functionality. Feedback and discussion on this proposal are welcomed to ensure a robust and effective implementation.