Conversation
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>
|
As mentioned in the meeting, this is still missing text about hosts generating |
|
|
||
| | Identifier | Name | Values | Deprecated | | ||
| |:----------:|:-------------------------|:---------------------------------------------------------------------------------------------------|:----------:| | ||
| | 0x0001 | `HAS_CORE` | When `1`, all baseline functions considered essential are supported. | No | |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Keeping the value part leaves the doors open for building upon this mechanism, instead of adding another one in the future, and I think we'll use it sooner rather than later.
Some things that come to mind would be:
- Some features might need to carry the value, e.g.
MAXIMUM_BUFFER_SIZE, 16384, - In case we want to allow "supported, but not enabled" use case, which would allow plugins to enable/disable some features at startup, e.g.
proxy_set_host_features(HAS_CUSTOM_FUNCTIONS, 1).
There was a problem hiding this comment.
Another use case that we might want to use is to define BASELINE_VERSION with random (or monotonic?) values while we're actively working on v0.3 implementations, before we freeze it as final BASELINE_VERSION=3000 or similar.
| | 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 | |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I disagree. Take Envoy for example, it currently supports only fully buffered (i.e. unary) HTTP callouts, so if for some reason we decided to rebuild gRPC support directly on top of HTTP callouts in SDKs, instead of relying on hosts to support gRPC, then we'd lose gRPC streams for callouts.
This is a hypothetical situation, and in such case we wouldn't have those features advertised here, but I'm just trying to show that some host features are not as well supported as they should be, and for example we don't have streaming HTTP callout because they're not supported in Envoy.
| | 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Correct. This is the same mechanism that's used by IETF and it works quite well during development, since backwards compatibility can be ignored when people are still working on implementations, because it's easy to switch to another random ID without any consensus.
| | 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 | |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
With any of the features here, host is agreeing to provide working implementations.
Stubs are always expected for proxy_* and wasi_preview1_* to support optional features (see: #91 (comment)), but the advertised features are expected to work.
| | Identifier | Name | Values | Deprecated | | ||
| |:----------:|:-------------------------|:---------------------------------------------------------------------------------------------------|:----------:| | ||
| | 0x0001 | `HAS_CORE` | When `1`, all baseline functions considered essential are supported. | No | | ||
| | 0x0002 | `HAS_LOGGING` | When `1`, all baseline functions for logging are supported. | No | |
There was a problem hiding this comment.
Are the SDKs expected to track which host features are supported and avoid invoking their hostcalls, or is it up to plugin authors to avoid calling such functions?
| - `INVALID_MEMORY_ACCESS` when `return_serialized_pairs_size` points to | ||
| invalid memory address. | ||
|
|
||
| This function is gated on [`HAS_HTTP_HEADERS`], [`HAS_HTTP_WITH_BODY`], |
There was a problem hiding this comment.
This is not clear to me if this method is exposed when any of the listed features are enabled or all of the listed features must be enabled to be exposed.
Can you clarify this in the spec for each function that has multiple features listed, to make it explicit?
3 participants
The
proxy_get_host_featureshostcall can be used by the SDKs todetermine which features are supported by the host environment.