ABI v0.3.0 scope & tracking issue

[PiotrSikora]

There are 3 groups of features that I believe should be addressed and implemented as part of ABI v0.3.0:

Fixes for well-known and outstanding issues:

• support multiple HTTP field values (modify proxy_get_header_map_value ABI to support returning values from multiple occurrences of the header #53),
• add ability to buffer and/or process HTTP request/response body before forwarding headers (a.k.a. "StopIteration") (HTTP: add more control over buffering and/or offloading processing to the host #63),
• add control over the end_of_stream flag when adding/removing HTTP parts (HTTP: add control of the end_of_stream flag #64),
• add ability to delete keys (Add the host function for removing shared data #32), list all keys, and check if a particular key exists (KVS: add ability to check existence of a given key without fetching it #70) in KV store,
• add ability to create and delete multiple instances of top-level resources (e.g. KV stores, queues, timers) (Add new/delete for most/all resources #58, Support for multiple tick periods (timers). #72),

Features that require changes to the existing function signatures, so it's better to get them in now:

• add explicit resource IDs in hostcalls (i.e. not automatically tracked by the host) (Context/resource ID should be always provided in the hostcall #59),
• use numeric IDs instead of strings for predefined values and identifiers (Use enums where possible #60),
• (maybe?) split features into groups (Group features into separate namespaces #57) with separate context types (ABI vNEXT: generic vs specialized context functions #9), potentially renaming them in the process,
• (maybe?) include protocol and socket type in proxy_on_{downstream,upstream}_* calls to support UDP and QUIC datagrams and streams (Support for writing for WASM for UDP  #31), or we could add separate functions for TCP, UDP and QUIC.
• (maybe?) consistent style in the ABI (expanded vs minimal) (Consistent style in the ABI (expanded vs minimal) #80).

Features for extensibility:

• add feature flags (additive, advertised only by the host) (Allow hosts to advertise features/settings at runtime #55), this can be also used for version negotiation when both host and plugin support multiple versions of the ABI, as well as for subsetting of features (Make most/all hostcalls optional #56),
• create registries (simple entries in markdown in this repo) for feature flags, foreign functions, properties, and status codes (Create registries for extension points #71), as well as hostcalls to list them.

Everything else can be done either using feature flags or FFI, so it can be added afterwards without ABI changes.

cc @mpwarres @martijneken @leonm1 @wbpcode @thibaultcha @shukitchan

[mpwarres]

@PiotrSikora one item not in the current list is #54 , for async KV get/set. Does that fall into the "Everything else can be done either using feature flags or FFI" category?

[PiotrSikora]

@mpwarres I think it would be helpful to keep new features out of v0.3.0 to avoid extra blockers and minimize number of changes to get things going... But the availability of "async K/V" is going to be advertised the same way whether it's an optional feature from v0.3.0 or something added via feature flags, so it really shouldn't matter one way or the other.