Discussion: What does it mean for Spin to support a wit interface

[rylev]

Note: This issue is meant to spark discussion and capture some ideas that have been floating around. SIPs and other issues will be opened to address aspects of this discussion.

Status Quo Support

Spin currently has support for several host wit worlds:

• fermyon:spin/host
• fermyon:spin@2.0.0/http-trigger-rc20231018
• fermyon:spin@2.0.0/http-trigger
• fermyon:spin@3.0.0/http-trigger
• spin:up@3.2.0/http-trigger

While Spin can support guests running against any of these guest worlds, support is specifically meant to be focused on the latest version. However, other worlds exist in the Spin ecosystem including those for spin-kube.

All of the currently supported worlds are fairly similar to one another, and we've largely had a policy of just appending new interfaces over time (the one large exception between the move from the fermyon:spin package to the fermyon:spin@2.0.0 package which made lots of breaking changes).

Expanding over time

As time goes on there's pressure to add more and more interfaces to Spin as users of Spin would like their guest applications to have new capabilities. This, however, presents a maintainability challenge not only in Spin but in the rest of the Spin ecosystem.

If the Spin ecosystem is forced to implement every new interface Spin should support, over time, we'll likely want to start moving to model where Spin only supports the absolute bare minimum number of interfaces - i.e.., the common dominator that the Spin maintainers deem every Spin application should have access to. This is a shame as it means that the use cases for Spin will be constrained to whatever can be solved by this common denominator of host functionality.

However, if we decide to go the opposite path and add an ever growing set of functionality, the maintenance burden on the Spin project will become every bigger. How can we move some of that maintenance burden to the growing Spin community in a model that incentives those who profit the most from niche functionality to be the maintainers of that functionality?

How do we solve this?

This issue is not meant to be a proposal for a solution here. There should hopefully be proposals coming soon from folks trying to solve aspects of this issue. Whatever solutions we come up should likely have the following properities:

• Give Spin applications a way to declare what functionality they depend on
• Give runtimes clear guidance on what functionality they need to support in order to be able to run at least a healthy sub-population of Spin applications
  • This seems the hardest to do as we have competing goals: promote portability across Spin compliant runtimes and allow expanding the set the of functionality a Spin app is allowed to rely on.
• Provide a framework for augmenting the Spin CLI runtime with additional host functionality without the Spin maintainers necessarily needing to be the primary maintainers of that functionality.

[lann]

One piece of the puzzle that we're still missing here is a good story around satisfying parts of a target world with component composition. Many of the imports that are currently implemented by the Spin host could plausibly be implemented as "library" components wrapping outbound http or sockets (e.g. KV, redis), or as "adapter" components that implement an older, less-capable interface in terms of a newer interface (e.g. fermyon:spin/http).