Rename `fermyon` namespace in Spin WIT

[kate-goldenring]

The Spin WIT files oftentimes use fermyon as the namespace for the packages. For example, the Spin 3.0 package is fermyon:[email protected]. As Spin is now moving to the CNCF, this namespace should be changed to something vendor neutral. The next major release of Spin is a good opportunity for this. We should start brainstorming naming options.

[kate-goldenring]

@itowlson is there a way we could make spin the namespace? It mainly gets confusing due to top level package name.

[lann]

Given that we need to continue supporting the existing names I'd propose leaving existing interfaces alone until actual revisions are needed. Some existing interfaces probably won't ever need to change again, especially where WASI equivalents are stabilizing (like wasi-keyvalue). We did something similar with the Spin-specific HTTP interfaces when wasi-http stabilized; it did not get migrated to the 2.0 package.

When we do need to update an interface, I'd suggest renaming to spin:<thing>, (like spin:llm).

We should pick a new name for the package holding the Spin world(s) since this can be visible in WIT tooling. Maybe spin:platform or something?

[itowlson]

+1 for leaving existing interfaces alone. Renaming existing interfaces seems like it would break all existing code.

Agree we should make spin (or something like that) the namespace for all future Spin-specific packages/interfaces.

[kate-goldenring]

Can we rename existing namespaces for Spin 4.0 and still maintain the old naming for 3.0 and lower packages? Essentially, if you inspected spin components in 4.0, ideally the word fermyon does not appear. This is by request of the CNCF.

[itowlson]

We can create parallel packages and interfaces (e.g. spin:platform/[email protected] identical to fermyon:spin/[email protected]) as long as we retain the existing packages and interfaces for back compat.

Spin must still export the vendorful packages/interfaces. Components built with pre-CNCF SDKs will still import the vendorful packages/interfaces. But yes we can (and should) make it so that components built with new Spin SDKs will import only neutral interfaces, opening a path to deprecating the vendorful packages/interfaces in time.

[lann]

I was about to write what @itowlson wrote 🙂. I was hoping we could do that migration lazily as needed but if we need to do it all at once we certainly can, it will just require a bunch of duplicate code in Spin.

[itowlson]

The top level package is now spin:[email protected]. Existing package names and namespaces are retained for backward compatibility.

The following APIs are now accessible via neutral interfaces:

• Command trigger: wasi:cli package
• Key-value: wasi:keyvalue package (DRAFT)
• MQTT trigger: spin:mqtt-trigger package
• PostgreSQL: spin:postgres package
• SQLite: spin:sqlite package
• Variables: wasi:config package (DRAFT)

The following APIs are still accessible only via vendorful interfaces:

• cron trigger: fermyon:spin-cron package
• LLM: fermyon:spin/llm interface
• MQTT (outbound): fermyon:spin/mqtt interface
• Redis (outbound): fermyon:spin/redis interface
• Redis trigger: seems to be defined only in a pre-versioning fermyon:spin/inbound-redis interface?
• MySQL: fermyon:spin/mysql interface