WebAssembly loader: Text format vs binary format

[jfblomgren]

The WebAssembly specification defines both a text format and a binary format. The purpose of the text format is to provide a human-readable format for WebAssembly and will usually be compiled to the binary format for execution.
The purpose of this discussion is to figure out whether the WebAssembly loader should accept both formats or only one of them, and how this should be accomplished.

To summarise the discussion so far, there are three possible options:

1. Only accept the text format. Since the standards-track C API for embedding WebAssembly does not support the text format, this would require the use of the non-portable wasmtime_wat2wasm to convert from the text format to the binary format. This adds a significant overhead and makes the loader less flexible if the user only has the binary format of their program, as it is easier to convert from text to binary than the other way around.
2. Only accept the binary format. This is completely supported by the C API and most efficient. Users that wish to work with the text format can then convert to the binary format themselves, and since Wasm is intended as a portable compilation target for other languages, passing a binary will probably be the most common use case anyway.
3. Accept both formats. This could be done by checking whether the data contains the Wasm binary header and converting from the text format if it does not. This would be the most flexible solution, but the header check adds overhead and it also has the same portability problem as the first solution.

[giarve]

I would discard the first option as it doesn't take into account the binary format, which is supposedly the most common use case and it doesn't have the compilation overhead because it is already compiled (faster function calls).

Now, we may have the same problem with the Java loader as the Java loader also has a text (.java) and binary format (.class). I am guessing that in wasm the compilation time/overhead would be smaller than in Java.

Currently in #145 it is specified that:

• load from file (load a java file).
• load from memory (eval).
• load from package (load a jar).

So there's no way to load a .class from memory as well.

Perhaps there should be a change in the API of Metacall to allow languages with bitcode/bytecode to be loaded from memory as well as from disk without checking for headers?