ayakoakasaka
commented
7 months ago I think it's up to the product to decide which solution to use, but if we're going to sell Wasm as a product, I think it has to be the latter. You are using NN as an example here, but I think this enumeration API system will also be necessary for other systems. So I hope there will be a lively discussion about this.
Any given model will have an embedded assumption about the version(s) of backends that will be able to consume it. There may be differences in one or more of:
When a model is loaded in the API, the behavior of mismatch is undefined. There is an "invalid-encoding" error type, but this does not disambiguate between the model actually being invalid or if the requested backend cannot handle the version of the model provided given the requested execution target or otherwise. (Is this supposed to be an "invalid-operation"?, we should document the errors expected for each API).
One possible solution would be to simply default to the new proposal of extended error information supplied along with the error code. This would be backend specific, requiring the caller to understand the syntax of what is returned. In the case of autodetected execution targets, discriminating information may not exist.
An alternate solution would be to provide an enumeration API which defines the supported backends. A supported-encodings() API could provide the encoding value and an extended version string. For example, the onnx encoding would be paired with a string specifying the SemVer of the equivalent runtime, e.g. "1.14.1"