Remove console_log support from the waPC standard
autodidaddict opened this issue · 2 comments
After going down the rabbit hole of providing an optional callback that can be used by consuming libraries to provide their own logging capabilities, it seems more obvious now that the console_log function is at the wrong abstraction level.
The waPC standard provides for the minimal set of WebAssembly calls required to facilitate bi-directional function calls. It definitely violates that abstraction to have the ability for the guest to make a direct console_log function.
If a guest module needs to request that its host perform a logging operation, then that should be a first-class waPC function call from the guest to the host, where the operation, namespace, and payload are something that both the host and guest understand. For example, this might be an operation called LogWrite in the namespace wascc:logging with a payload containing the debug log level, the text of the log output, and potentially other metadata.
CC'ing @pkedy for potential discussion on this issue as removal of that call from the Rust host has implications that it should be removed from the standard and therefore not supported by any host runtime.
After discussing the issue, it seems like we've conflated two different forms of logging. The console_log function is supposed to be documented as a very simple println alternative for wasm modules that do not have WASI access to the equivalent host function. This is not the same thing as structured logging targeted at being parsed or consumed by downstream entities.
In other words, there is room for both console_log and first-class RPC operations that perform robust log writing.
As a result, waPC's console log implementation can stand as-is, and we can chock this rabbit hole adventure up to how easily conflated "println" logging is with structured, robust logging.