[PROPOSAL: DRAFT] Vignette Assets

[LeNitrous]

Motivation

Vignette is all about being lightweight and customizable. This gives full control to the user on how they want their workspace is handled. With that in mind, an assets marketplace (preceding the original "extension system" concept). This allows third parties to have to share assets from images, sounds, and new features extending Vignette's functionality in general.

This is in part as to how Vignette is licensed. Namely the GPLv3 with SDK Exception allows others to create addons with their own licensing terms as an effort to provide a healthy ecosystem for both developers, asset creators, and consumers.

Structure

The Vignette Asset will use the extension .vast which is basically a zip archive with no compression. This is to make delivery of assets from the marketplace or anywhere else easy and easily distinguishable. The contents of the archive will be as follows:

resources/
├─ sounds/
├─ models/
├─ textures/
libraries/
├─ runtimes/
│  ├─ win-x64/
│  ├─ linux-x64/
meta.json

Resources

This contains generally assets that are needed by the extension. This is for assets that provide new content in Vignette For assets to be properly loaded, all sound files must be in their respective subdirectories: sounds, models, and textures. For library developers, they have full control of reading content inside the resources directory.

Libaries

This contains library files that are loaded and ran by the extension host. The entry point library file is defined in the metadata. Unmanaged libraries are to be placed inside the runtimes directory followed by a directory named after the .NET Runtime Identifier of their target.

meta.json

This file contains metadata about the extension itself. It will be explained further in the next section:

Metadata

The metadata is a JSON file and will contain information about the extension, its intents, and how it will be read by Vignette. It will be structured as follows:

{
  "id": "My.Extension.Library",
  "name": "My Extension",
  "author": "The Vignette Authors",
  "engine": "1.0.0-github-public",
  "version": "1.0.0",
  "type": "library",
  "dependencies": [
    {
      "id": "My.Extension.Assets",
      "version": "1.0.0",
    }
  ],
  "intents": [
    "workspace",
    "tracking",
    "widget"
  ]
}

[sr229]

Just some additional stuff to cover here:

Security and Reliability Considerations

Vignette will implement an out-of-process approach on loading user extensions, this involves using an Extension Host with a gRPC implementation of the internal Extension API. The Extension Host also contains ACLs to prevent arbitrary system calls using the .NET standard library. This design consideration allows to maintain security and prevent malicious actors from loopholing the SDK due to unrestricted access.

[sr229]

Hello everyone, we went to the drawing board today and decided to investigate our Extension Architecture once more. We decided on something plain and simple, while still meeting our fundamental requirements, with that in mind, this is the result of our discussion.

Vignette Modular Architecture 2.0

Inspired of the NT Kernel's architecture, Vignette's architecture is designed to be simple, minimal, and flexible. We kept the core simple and only contain the necessary facilities to make the extensions, as we're going for an extension-first architecture. The new architecture composes of the following:

• the Public API is going to be everyone's entry point into making their own extensions. It's all-encompassing and provides all the necessary facilities for you to make your extension. As much as possible we want to cover a lot of your use cases like file parsing, rendering, UI, etc. So you don't need to use external libraries on the most common cases.

• the Internal API is what the Public API uses to provide these facilities, this is where we usually implement the low-level primitives used by the public API and "privileged" APIs that can only be used by extensions compiled with the application (we call this vendor extensions). In most cases you won't need the internal APIs here, but if you do for example, we can easily expose it.

[sr229]

We are happy to announce this proposal has now graduated into a full specification for implementation. See #251. We've also simplified the way extensions will be made by using an industry-tested scripting engine, ClearScript, and will allow you to write extensions using TypeScript.

All further discussion must happen on GH-251 now.