Global daemon/service

[claytercek]

TLDR

Evolve the current CLI tool into a flexible system that supports both the existing CLI workflow and optional daemon-based operation with multiple interfaces (HTTP, WebSockets, etc.). The architecture prioritizes backward compatibility.

Current Architecture

graph TD
    CLI["CLI Tool"] --> |uses| Config["launchpad.config.ts"]
    CLI --> Logic["Content/Monitor Logic"]

Loading

Target Architecture

graph TD
    CLI["CLI Tool"] --> |direct mode| DirectCmd["Command Router (Direct Mode)"]
    CLI --> |daemon mode| Daemon["Daemon Process"]
    
    HTTP["HTTP API"] --> Daemon
    WS["WebSockets"] --> Daemon
    
    Daemon --> Registry[(Project Registry)]
    Daemon --> DaemonCmd["Command Router (Daemon Mode)"]
    
    DirectCmd --> Handlers["Command Handlers"]
    DaemonCmd --> Handlers
    
    Handlers --> |dynamically loads| Config["Project launchpad.config.ts"]
    Handlers --> Core["Content/Monitor Logic"]

Loading

Key Architecture Components

1. Multi-layered Architecture

• Core Layer: Contains all app management logic (content and monitor packages)
• Command Layer: Implements the command pattern for all operations
• Interface Layer: Multiple interfaces (CLI, HTTP, WebSockets)
• Discovery Layer: Smart routing between direct execution and daemon

2. Command Pattern Implementation

All operations are encapsulated as commands, enabling:

• Consistent execution across interfaces
• Clear separation of concerns
• Testability and composability

3. Smart Daemon Discovery

• CLI automatically detects if daemon is running
• Routes commands to daemon when available
• Falls back to direct execution when needed
• No changes required to existing workflows
• HTTP/WebSocket interfaces always use the daemon

4. Configuration Management

• Project-level config.ts files remain unchanged
• Project registry stores paths to configs, not the configs themselves
• Daemon dynamically loads configs when needed
• Preserves non-serializable elements (functions, complex objects)
• Project registration process manages the mapping

5. Package Separation

• content/monitor: Core functionality, command definitions
• cli: CLI interface with smart routing
• daemon: Daemon process, project registry, IPC layer
• server: HTTP/WebSocket server, connects to daemon

Refactoring Path

Phase 1: Command Pattern Refactoring

1. Extract core functionality into command objects
2. Implement command registry and router
3. Refactor CLI to use the command pattern
4. Ensure all tests pass with direct execution

Phase 2: Daemon Implementation

1. Implement daemon process
2. Add IPC/socket communication layer
3. Create daemon discovery mechanism
4. Add daemon installation/uninstallation commands
5. Implement project registration system

The daemon implementation will include a project registry that stores paths to project configs rather than the configs themselves:

{
  "projects": [
    {
      "id": "main-exhibit",
      "projectPath": "/path/to/project",
      "configPath": "./launchpad.config.ts",
      "lastRegistered": "2025-04-01T12:00:00Z",
      "metadata": {
        "name": "Main Exhibit",
        "description": "Primary exhibit application"
      }
    }
  ]
}

When commands need to be executed, the daemon will:

1. Locate the project in the registry
2. Dynamically load the config file using ts-node or similar
3. Execute the command with the loaded config
4. Return results to the caller

Phase 3: Server Implementation

1. Implement the HTTP server package separate from the daemon
2. Add WebSocket or other protocol support (?)
3. Create authentication/authorization layer

The server will:

1. Connect to the daemon process via the local socket
2. Translate HTTP/WebSocket requests into commands
3. Send commands to daemon for execution
4. Return results to clients

Technical Considerations

Backward Compatibility

• No breaking changes to existing CLI commands
• Transparent daemon discovery
• Graceful fallback to direct execution
• Support for existing config formats and structures

Security Considerations

• Local socket permissions - we should probably make a new user group ("launchpad")
• Optional authentication for network interfaces
• Secure storage of configuration paths
• Validation of project paths during registration