Support wasi-keyvalue

[endocrimes]

wasi-keyvalue is relatively complete as an interface and the core interface (https://github.com/WebAssembly/wasi-keyvalue/blob/main/wit/store.wit) is almost identical to spin-kv (https://github.com/fermyon/spin/blob/main/wit/key-value.wit) with the primary difference being the exists function.

We should add support for wasi-keyvalue to get broader ecosystem compatibility - and the ability to benefit from the extended interfaces over time.

[itowlson]

@endocrimes Can you expand on the difference you identified around the exists function please? They look the same to me but I'm not terribly au fait with the wasi-keyvalue side.

(The main difference I did run into was around list-keys accepting a cursor for paging.)

[endocrimes]

Past me forgot to link to a revision, but that got added since I last looked 😅 - now there's no meaningful difference 🎉

[mikkelhegn]

@itowlson - We talked about this in today's Spin Up meeting. There is a release going out early next week. If there is an opporutnity to get this in, it's possible. If not, we can move it to post release in the board.

[itowlson]

@mikkelhegn There is a PR out. The first step towards a release would be to get feedback on that, specifically on the critical question of how to manage the Spin world versioning. I'll ping the reviewers.

[lann]

the critical question of how to manage the Spin world versioning

Notably, this is basically the entire focus of WASI 0.2.1 and afaik we still haven't even completely figured out versioning for that upstream.

[itowlson]

@mikkelhegn given ^^ I think it is fair to say this will not be part of 2.6

[devigned]

Hey folks 👋, I'm happy to volunteer to implement the rest of the WASI key/value interface (atomics and batching) to help provide the basis for a second provider implementation for the interfaces, which will enable it to graduate to phase 3. Would the project be interested in the contribution?

[itowlson]

@devigned The project would be absolutely delighted - thank you! I've just rebased #2486 onto latest main - I don't know whether it's more convenient for you to PR onto that or to take a new branch from it and create a new PR - whatever suits you.

As you're aware, #2486 only covers the store interface, because that is what we already had code for. The batch and atomics interfaces would require wholly new code, which I expect would be routine API calls for the Redis and Azure backing stores, but we also have a SQLite store for local dev use. I expect batch would be easy to implement on that; atomics might involve a bit more faff. I'm happy to collaborate if need be of course! And apologies if I'm telling you things you already know.

Thanks again!

[devigned]

My plan is to make a new branch from yours and create a new PR. I don't want to muddy your existing work while I fiddle.

As you're aware, #2486 only covers the store interface

Yes. I talked with @kate-goldenring about each of the impls. I believe I should be able to implement the rest of the interface over the data stores. The SQLite store may need a schema change, but I don't think it should be too bad. It'll be a great opportunity to test that the k/v interface will work well with multiple data stores.

I really appreciate your support and will likely take you up on the offer to collaborate.

[itowlson]

@devigned Did you get the chance to look at this? I know stuff has got in the way - not nagging just checking in. Thanks!