toolz/goplt
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6a172364748eb7e13495646dc4a29e56f77bfe28
goplt/docs/adr/0021-module-loading-strategy.md
0x1d 6a17236474 docs: add implementation plan, ADRs, and task tracking system 
- Add comprehensive 8-phase implementation plan (docs/plan.md)
- Add 28 Architecture Decision Records (docs/adr/) covering all phases
- Add task tracking system with 283+ task files (docs/stories/)
- Add task generator script for automated task file creation
- Add reference playbooks and requirements documentation

This commit establishes the complete planning foundation for the Go
Platform implementation, documenting all architectural decisions and
providing detailed task breakdown for Phases 0-8.
2025-11-04 22:05:37 +01:00

1.7 KiB
Raw Blame History

ADR-0021: Module Loading Strategy

Status

Accepted

Context

The platform needs to support pluggable modules. Two approaches:

  1. Static registration - Modules compiled into binary
  2. Dynamic plugin loading - Load .so files at runtime

Each has trade-offs for development, CI, and production.

Decision

Support both approaches with static registration as primary:

  1. Static registration (primary):

    • Modules register via init() function
    • Imported via import _ "module/pkg" in main
    • Works everywhere (Windows, Linux, macOS)
    • Compile-time type safety

  2. Dynamic plugin loading (optional):

    • Support via Go plugin package
    • Load .so files from ./plugins/ directory
    • Only for production scenarios requiring hot-swap
    • Linux/macOS only (Go plugin limitation)

Rationale:

  • Static registration is simpler and more reliable
  • Works in CI/CD (no plugin compilation needed)
  • Compile-time safety catches errors early
  • Dynamic loading provides flexibility for specific use cases
  • Modules can choose their approach

Consequences

Positive

  • Flexible: static for most cases, dynamic when needed
  • Static registration works everywhere
  • Compile-time safety with static
  • Hot-swap capability with dynamic (Linux/macOS)

Negative

  • Two code paths to maintain
  • Dynamic plugins have version compatibility constraints
  • Plugin debugging is harder

Implementation Notes

  • Implement static registry in internal/registry/registry.go
  • Modules register via: registry.Register(Module) in init()
  • Implement plugin loader in internal/pluginloader/plugin_loader.go (optional)
  • Document when to use each approach
  • Validate plugin version compatibility if using dynamic loading