Plugin Architecture

d3 supports two types of plugins: internal and remote. Each type has its own characteristics and use cases.

Internal Plugins

Internal plugins are stored directly within the project folder structure:

{project_path}/
  └── plugins/
      └── my-plugin/
          ├── index.html
          ├── index.js
          └── ... other plugin files

or alternatively can be stored in the common folder, making them accessible to all projects on that machine:

common/
  └── plugins/
      └── my-plugin/
          ├── index.html
          ├── index.js
          └── ... other plugin files

Characteristics

• Persistence: Internal plugins are stored with the project file and persist across project copies and transfers
• Portability: The plugin travels with the project, making it ideal for project-specific customizations
• Version Control: Plugin versions are tied to the project version
• Offline Support: Internal plugins work without network connectivity
• Project Isolation: Each project can have its own version of the same plugin
• Frontend Only: Internal plugins are limited to HTML/JavaScript and cannot include backend services

Use Cases

• Project-specific customizations
• Show-specific tools and utilities
• Offline-capable plugins
• Version-locked plugins that must remain compatible with a specific project
• Simple UI tools that don’t require server-side processing

Remote Plugins

Remote plugins are discovered using DNS-SD (Bonjour) on the network:

_d3plugin._tcp.local.

Characteristics

• Discovery: Automatically discovered on the network
• Centralized Management: Plugins are managed at the appliance level
• Real-time Updates: Plugin updates are immediately available to all projects
• Network Dependency: Requires the appliance to be online
• Shared Resources: Same plugin version is used across all projects
• Full Stack: Remote plugins can include both frontend and backend components

Architecture

Remote plugins typically consist of two parts:

1. Frontend: HTML/JavaScript interface
2. Backend: A separate application that handles server-side processing

Use Cases

• System-wide tools and utilities
• Shared plugins across multiple projects
• Plugins requiring network connectivity
• Plugins that manipulate or are hosted by a third party device (eg an LED processor configuration plugin)
• Plugins that need centralized management
• Complex plugins requiring server-side processing
• Plugins that need to maintain state across sessions

Working Together

Both types of plugins can coexist in the same project:

1. Internal plugins are loaded when the plugins button is clicked
2. Remote plugins are discovered and loaded as they appear in the DNS-SD registry

Best Practices

1. Choose the Right Type

   • Use internal plugins for project-specific needs
   • Use remote plugins for system-wide tools

2. Version Management

   • Keep internal plugin versions in sync with project requirements
   • Document version dependencies in plugin manifests

3. Network Considerations

   • Ensure critical plugins are internal if offline operation is required
   • Consider network availability when designing plugin dependencies

4. Resource Management

   • Monitor plugin size and loading times
   • Consider impact on project file size with internal plugins