DDS Plugin SDK#

Check the current plugin development status, source examples, and the proposed public SDK boundary.

Current Status#

Reviewed October 3, 2026. DDS has specific desktop integrations and a public Verilator source preview. A supported standalone plugin SDK and a general third-party plugin loader have not been released. The publication design below is a development plan, not a stable API or an installation command.

Use this documentation for development guidance, GitHub for versioned source and contributions, and a released package or archive for an installable SDK when one becomes available. Marketplace integrations have their own host and execution limits.

Try the Existing Source Preview#

The Verilator adapter source contains original argument-planning code and tests. Its README specifies Node 22. Review the source, then run its tests:

Bash
git clone https://github.com/Altifigence/dds-verilator-plugin.git
cd dds-verilator-plugin
npm test

Version 0.1.0 validates a bounded saved-source bundle and produces a lint command plan. It does not read workspace files, download or run Verilator, or install into DDS. Its manifest is a draft that the DDS host does not consume. The repository is public; npm package publication is disabled.

What the Public SDK Should Contain#

The proposed SDK is a small development package that can be understood and tested independently. API prose is accompanied by usable code and examples. Each public file needs a clear license and a reviewed source origin.

Public material

Purpose

Versioned manifest, permissions, messages and result schemas

Validate plugin identity, compatibility, declared access and inputs/outputs

Small type definitions, validators and host-facing client interfaces

Provide editor assistance and predictable errors without importing whole engines

Working mock-host examples and contract tests

Let developers run a first example, cancellation and failure cases without production credentials

API reference, compatibility matrix and release notes

Explain host support, changes, migration and the exact released package

The public package does not need DDS private UI, engine implementations, account or billing services, host signing keys, credentials, customer data or execution-policy internals. Public API declarations do not grant filesystem, network, process or Cloud access. Those decisions remain with the host.

Language Plugins and Host Support#

The design targets completion, hover, signatures, definitions, references, document symbols and diagnostics. It must specify registration and disposal, document versions, cancellation, bounded results, and errors for unsupported hosts. These are proposed contracts; there is no public registration API to call today.

Desktop Windows, desktop Linux and browser Cloud require separate capability declarations. A mock-host test demonstrates an example contract. Real host compatibility requires tests against the named DDS release and operating system.

Performance and Developer Experience#

  • Keep the initial SDK small. Load only the API family a plugin uses and activate a plugin only when its feature is needed.

  • Run heavy parsing and external tools outside the editor thread. Use bounded asynchronous requests, cancellation and host resource limits.

  • Cache work by source identity, tool version and relevant options; invalidate it when any of those inputs changes.

  • Measure package size, cold activation, memory, request p50/p95, cancellation latency and large-project behavior. Check the same fixtures and hardware before claiming an improvement.

  • Provide one small starter example, a mock host, typed errors and an upgrade guide. Publishing an example is useful even before production execution is available.

Repositories, Versions and Contributions#

The planned SDK home is an independent repository in the Altifigence GitHub organization. Begin with SDK code, examples and contract tests together so they match one release. Mature tool adapters can have their own repositories when their maintainers or release schedules differ. A repository for every catalog entry is not a licensing requirement by itself.

Publish only a reviewed file list. Bind source, schemas, package contents, license notices and documentation to the same version. Test the actual package archive outside the DDS monorepo before publishing it. Previews must state their limits; a version tag alone does not establish host compatibility.

The existing Verilator adapter accepts source review through its GitHub repository. Its Apache-2.0 license covers its original files; upstream tool material retains separate terms. A future SDK license will be stated in that SDK repository and release.

Updates and Security#

The proposed maintenance flow detects upstream releases, prepares a version-pinned update, checks license changes and compatibility in an isolated environment, and opens a reviewable pull request. Only a reviewed package should enter a supported release channel. This page does not announce an automatic updater or malware certification service.

Package signatures and hashes identify publishers and expected bytes; they do not prove that code is harmless. Review declared access and the current third-party tool boundaries. A general community plugin execution service needs isolation, limits, revocation and incident handling before it is offered.