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

Note: Internal plugins run within Designer’s embedded Chromium browser engine, providing access to modern web technologies and JavaScript frameworks. However, they are served using HTTP (not HTTPS), which means certain browser features that require a secure (HTTPS) context will not work. This includes (but is not limited to):

• Accessing hardware device APIs such as WebUSB, WebBluetooth, and WebHID
• Use of service workers or features requiring Push Notifications
• Accessing the clipboard via asynchronous Clipboard API
• Features like WebAuthn (authentication via hardware security keys)
• Access to getUserMedia for camera/microphone may be restricted or display security warnings
• Persistent storage via StorageManager might be unavailable
• Some integrations with Payment Request API and other sensitive APIs

If your plugin relies on any feature that requires HTTPS, please verify if it will function properly in the embedded browser context.

For the latest information about which Chromium instance is supplied, see the Chromium Web Integration page in the Disguise user guide which lists the different versions for each Disguise Designer version.

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