Hey everyone,

At this point in time, proto is relatively stable, and we believe an official v1 is around the corner. Before we do that though, we want to hear from the community about what they would like to see in the project. We have a few ideas of our own (below), but we want to make sure we're not missing anything useful.

We want to gather this feedback now incase we need to introduce breaking changes, which we'd like to do before v1. We're also open to collaborating on these features, so if you're interested in working on something, let us know!

Current roadmap

Build from source

Building from source is required to support additional languages, like PHP and Ruby, but can technically be used for any language as an alternative to pre-builts. We've started working on this, but it's quite hard to nail down a Rust/WASM API since every language builds from source differently.

Unlocks:

• New languages to support.
• Can customize what features/extensions are enabled for the language (for example, PHP may want mysql).
• Supports versions of languages that may not have pre-builts.

Blockers:

• Not enough research on how every language builds from source.
• How to distinguish versions with different requirements?
  • For example, 1.2+mysql and 1.2+pgsql.
  • Both for configuration and folder structure.

More built-in languages

We would like to support more languages out of the box, primarily web-based languages like PHP, Ruby, and Python (provide better support). Other languages outside of this list will be supported by the community.

Blockers:

• Requires building from source.
• Someone with better knowledge of these languages.

Backlog

Plugin registry

Right now, plugins are supported using file system paths or secure URLs, but both of these have limitations. What proto really needs is some kind of central registry in which the .wasm files can be stored and accessed. This will also allow for metadata, versioning, and self-management by users.

Unlocks:

• Single source of truth.
• Can search for plugins (proto plugin search).
• Can associate metadata to plugins (name, description, author, version, etc).
• Avoids having to configure [plugins] (for the most part).
• Users can self-manage their plugins (publish, update, delete).
• Maybe have a nice browser UI.

Blockers:

• Have to build the registry from scratch (not aware of an off the shelf solution).
• May be costly to run (storage, bandwidth, etc).
• How does this work with TOML plugins?
• Is it worth it?

Lockfiles/checksums

We would like to generate lockfiles and checksums for all downloaded plugins. This is difficult with our current implementation, as no checksum/metadata is associated with file system paths or secure URLs when downloading plugins.

Unlocks:

• Ensure the safety of our users and their machines.
• We avoid executing potentially malicious .wasm files (is this even possible with WASM's sandbox?).

Blockers:

• Most likely requires a plugin registry to be effective (unless someone has a great idea/alternative).