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 (#53),
• [ ] add ability to buffer and/or process HTTP request/response body before forwarding headers (a.k.a. "StopIteration") (#63),
• [ ] add control over the end_of_stream flag when adding/removing HTTP parts (#64),
• [ ] add ability to delete keys (#32), list all keys, and check if a particular key exists (#70) in KV store,
• [ ] add ability to create and delete multiple instances of top-level resources (e.g. KV stores, queues, timers) (#58, #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) (#59),
• [ ] use numeric IDs instead of strings for predefined values and identifiers (#60),
• [ ] (maybe?) split features into groups (#57) with separate context types (#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 (#31), or we could add separate functions for TCP, UDP and QUIC.

Features for extensibility:

• [ ] add feature flags (additive, advertised only by the host) (#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 (#56),
• [ ] create registries (simple entries in markdown in this repo) for feature flags, foreign functions, properties, and status codes (#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.