Proposal Info
Areas: Extensions
Proposal Type: New Feature
Overview
This proposal describes requirements for a minimal set of functionalities, that incoming extension system must contain and how the overall design should look.
Extensions Host: WASI - Wasmtime Engine
Scripting Languages: System is language agnostic, C# SDK maintained by us, community support for other SDKs
Sandboxing: Ensured by WASI, managed by granular permission system
Versioning, ABI compatibility
System design should ensure maximum forwards and backwards compatibility. Extension written for earlier version of PixiEdior should not break in newer versions. Any ABI breaking changes should be properly versioned and gradually deprecated.
ABI compatibility is a technical problem, which can be solved with proper versioning.
PixiEditor’s API should be versioned and updated with SDK versions. On startup, PixiEditor should exchange information with the extension with ABI version to use. Whole setup should be automatic and frictionless.
Logical compatibility
Much more challenging problem is logical compatibility. Things like:
- Manipulating Visual Tree,
- Cross extension interactions,
make extension much more prone to breaking, even though ABI is intact.
A proper solution for potentially breaking logical compatibility must be solved case by case.
Capabilities
In a minimal version, PixiEditor’s extension system should allow extension to:
- Manipulate pixels data of image layers,
- Manipulate vector data of vector layers,
- Accessing other layer data,
- Traversing and manipulating Layer Tree,
- Traversing and manipulating Node Graph,
- Allow for exporting and importing,
- Ability to create custom file parsers,
- Invoke native PixiEditor commands,
- Register own commands,
- Embed resources and load them,
- Create custom popups and UI elements,
- Manipulate Visual Tree of PixiEditor,
- A way to define own Nodes
- Access to preferences and local data
Dependencies
Having access to .pixiext should mean fully working PixiEditor extension.
Language level
Each extension should be self-contained on language level, meaning that all dev dependencies must be included within the extension. An extension can’t be dependent on any OS-level library. This is ensured by using WASI modules.
Other extensions
Extensions should be able to depend on other extensions, however to comply with
Having access to
.pixiextshould mean fully working PixiEditor extension.
Each extension should bundle all dependencies within itself. Upon unpacking the extension by PixiEditor, bundled dependencies may be ignored if they are already installed independently.
Resolving conflicts
There may be a conflict, where bundled dependency’s version is lower than indepndendly installed extension. This should be resolved by interoperability design. See Cross-extension interoperability and command system section.
Permissions
Sandboxing ensured by WASI makes extension security much easier. PixiEditor’s extensions should follow strict permission system and inform users what they can expect from the extension.
Calling permission protected ABI functions without enabling permission flags within extension manifest, should result in error. Example areas, where permissions should be required:
- Accessing non-owned preferences (overwriting preferences of other extensions and PixiEditor itself)
- IO operations
- Network access
- Modifying visual tree
Other security
PixiEditor should protect modifying and overwriting UI elements added by other extensions and PixiEditor itself. This would prevent hijacking well known elements by malicious extensions.
There should be a way to allow extension doing that, by explicitly enabling proper permission or specifying what elements can be overwritten/replaced this way.
Cross-extension interoperability and command system
PixiEditor’s command system specifies an action under unique name, like “PixiEditor.Document.Resize”.
Extension should be able to declare their own commands, that can be used by other extensions.
Both PixiEditor’s and extension command system should be versioned. This decreases chances of incompatible versions of dependecies.
Library extensions that properly version their commands, should provide full backwards compatibility.
Transactions
An idea by @Matalya, performing commands or some changes, should work transactionally. Similar to database transactions, multiple changes should be executed together and rolled back to pre-transaction state easily.
.pixiext structure
.pixiext is a PixiEditor extension format. In reality it is a .zip with
extension.json- extension manifestLocalization/*.json- language filesResources/- additional files for extension, such as images. Extension has an option to encrypt resources, so the contents is onlyresources.data, instead of actual files.
Entryless extensions
Some extensions don’t need code. For example language extensions, color themes, brush packs or other data based addons.
This can be detected automatically or specified in extension.json and loaded by PixiEditor. They can be automatically considered fully safe and hot reloaded.
Console
PixiEditor should have built-in extension console, which displays extension logs and errors. Additionally, it should be possible to invoke extension commands from within the console.