Skip to content

PLUGIN_ARCHITECTURE.md

Latest commit

 

History

History
79 lines (59 loc) · 2.52 KB

PLUGIN_ARCHITECTURE.md

File metadata and controls

79 lines (59 loc) · 2.52 KB

Plugin Architecture

Why This Architecture?

This plugin system solves the fundamental tension between modularity and performance in desktop applications. Unlike traditional plugin systems that load everything at runtime, we use a three-tier approach that optimizes for both developer experience and end-user performance.

The Three-Tier System

1. Registry (Single Source of Truth)

The registry.json file controls the entire plugin lifecycle:

{
  "plugin-name": {
    "compiledIn": true,      // Include in build?
    "defaultEnabled": true   // Active by default?
  }
}

This centralized approach eliminates the configuration drift that plagues distributed plugin systems.

2. Build-Time (Conditional Compilation)

Plugins are conditionally compiled based on Cargo features:

  • Why? Zero overhead for unused plugins - they don't exist in the binary
  • How? Registry drives Cargo feature flags automatically
  • Result: Production builds contain only what's needed

3. Runtime (Chrome-Style Flags)

Users can enable/disable compiled-in plugins without rebuilding:

  • Disabled plugins have no performance impact (code never loads)
  • Settings persist across sessions
  • No restart required

What Makes This Unique

Traditional Plugin Systems:

  • Load all plugins, disable some at runtime
  • Plugin code always present in memory
  • Configuration scattered across multiple files
  • Runtime discovery overhead

Our Approach:

  • Compile only what's needed
  • Registry as single configuration source
  • Zero-cost abstraction for disabled features
  • Predictable, auditable plugin loading

Key Design Decisions

Conditional Compilation as a Feature

We intentionally chose compile-time inclusion over runtime loading because:

  1. Security: No arbitrary code execution
  2. Performance: Dead code elimination at compile time
  3. Reliability: All plugins verified at build time
  4. Size: Minimal binary contains only core features

Registry-Driven Development

The registry pattern provides:

  • Single place to enable/disable features
  • Automatic build configuration
  • Clear separation between "available" and "active"
  • Version-controlled plugin state

Plugin Loading Flow

registry.json → Cargo features → Binary compilation
     ↓                               ↓
User settings ← Runtime flags ← Compiled plugins
  1. Registry determines what gets compiled
  2. Build system reads registry, sets features
  3. Only compiled plugins can be enabled at runtime
  4. User preferences stored separately from registry