Type specialization

[jedisct1]

In high-level APIs, having distinct types, with their own methods, for each class of algorithm (or even for each algorithm), is a common and safe thing to do.

Doing the same thing in a WITX interface definition is not as natural. Types and functions are defined independently. So, we end up with type definitions, and long list of functions, making the API hard to follow.

An example of this in wasi-crypto is keys. Signatures and key exchange mechanisms use secret and public keys, joint or disjoint. These deserve different purposes, and it would make sense to have different types for keys related to signing and keys related to every kind of key exchange mechanism. Because this is likely how high-level APIs will eventually look like anyway.

However, specialization quickly causes an apparent explosion of the number of functions, similar to what we would get by exporting a flat list of symbols from a typical high-level API.

Hence, https://github.com/WebAssembly/wasi-crypto/pull/27 that adds a new asymmetric-common module, defining generic secret key, public key and key pair types and common methods that can be shared by other modules.

This helps a lot with keeping the API small and readable.

But, having something closer to what high-level APIs will look like would be way better. And at implementation layer, more specialized types means less dynamic dispatch to do, which reduces complexity.

In reality, having to balance between a long API and something compact/readable is not a limitation of WASI APIs.

This is just a limitation of the currently available tools. There are no reasons for tools and formats (e.g. WITX) not to eventually provide elegant ways to solve these limitations. Some discussions already started around the idea of providing annotations to link types and functions in order to describe classes.

Maybe a plan can then be:

• If factorizing a few types currently result in a significantly smaller API, do it.
• Once WITX and code generators provide better support to describe classes (and other structures, such as traits and inheritance), leverage these to switch to finer grained types.

Alternatively, we can look at splitting the API into many more modules.

What do you think?

[jedisct1]

WAI and WIT do that, more or less.