Skip to content

Conversation

@PiotrSikora
Copy link
Member

The proxy_get_host_features hostcall can be used by the SDKs to
determine which features are supported by the host environment.

The `proxy_get_host_features` hostcall can be used by the SDKs to
determine which features are supported by the host environment.

Signed-off-by: Piotr Sikora <code@piotrsikora.dev>
@PiotrSikora
Copy link
Member Author

As mentioned in the meeting, this is still missing text about hosts generating UNIMPLEMENTED stubs for any imports starting with proxy_ to avoid linking-time issues during loading phase for imports supported/expected by guests but not implemented yet by the host.


| Identifier | Name | Values | Deprecated |
|:----------:|:-------------------------|:---------------------------------------------------------------------------------------------------|:----------:|
| 0x0001 | `HAS_CORE` | When `1`, all baseline functions considered essential are supported. | No |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it's best to be explicit, but just out of curiosity, is there ever a case where this bit wouldn't be set?

| 0x0004 | `HAS_HTTP_WITH_BODY` | When `1`, all baseline functions for HTTP are supported. | No |
| 0x0005 | `HAS_HTTP_CALLS` | When `1`, all baseline functions for HTTP calls are supported. | No |
| 0x0006 | `HAS_GRPC_CALLS` | When `1`, all baseline functions for gRPC calls are supported. | No |
| 0x0007 | `HAS_GRPC_STREAMS` | When `1`, all baseline functions for gRPC streams are supported. | No |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it's worth it to separate streaming from unary gRPC, it's hard for me to imagine a host supporting only non-streaming gRPC.

| 0x0F01 | `HAS_WASI_PREVIEW1_CORE` | When `1`, all baseline functions considered essential from WASI Preview1 are supported. | No |


Identifiers below 0x2000 are reserved for standardized features and options. Random numbers above that range should be used for private extensions.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you expect that when a new feature intended for eventual standardization is added, it would start off with an ID above 0x2000 while still in experimental state, and then later switch to a standard ID?

| 0x000D | `HAS_METRICS` | When `1`, all baseline functions for metrics are supported. | No |
| 0x000E | `HAS_PROPERTIES` | When `1`, all baseline functions for properties are supported. | No |
| 0x000F | `HAS_CUSTOM_FUNCTIONS` | When `1`, all baseline functions for custom functions are supported. | No |
| 0x0F01 | `HAS_WASI_PREVIEW1_CORE` | When `1`, all baseline functions considered essential from WASI Preview1 are supported. | No |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With HAS_WASI_PREVIEW1_CORE, is the host agreeing to provide at least stub hostcalls for all WASI Preview1 hostcalls, or is it only exporting a selected subset of the WASIp1 hostcalls?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants