Extensibility

[Felix-El]

To me, wasi-logging is missing the essential fields filename and line. Other users are likely missing other fields. How about adding a semi-opinionated extra: list<tuple<string, string>> that could accommodate for special needs? A curated set of "assigned" (agreed upon) keys could be described in the documentation and people would not need to upgrade the interface to have support for new fields. This seems like a best effort pragmatic approach compatible with logging.

This would maybe also replace the context field, which seems under-specified. There can be anything in context which makes it hardly machine-readable. With a dictionary like extra a tool would at least know some structure and may look out for specific keys to handle in specific ways.

[ricochet]

The implementation of the log may or may not be written to a file. In review of prior art, I see that Go has a Source type for where the log statement is emitted. In practice, this is usually used by logging providers vs the guest/app caller. That also aligns with how providers are treated in Logging in .NET Core and ASP.NET Core.

In the current version of this API, context is functionally equivalent to category. We could rename and document if that helps clarify.

For making runtime level extensions, there is wasi:config/runtime. This could be a way to set opinionated options for a logging provider or host runtime implementation. Generally for WASI API's, we aim to provide concrete and semantic types for our interfaces vs property bags.

FYI, this is a phase 1 proposal with only one implementer that I'm aware of, so we can definitely make changes.

[Felix-El]

Maybe my expectations toward logging are a bit more low-level. Here are some examples:

• https://docs.python.org/3/library/logging.html#logrecord-objects LogRecords have some concrete low-level properties like pathname to source file, lineno and func but also allow for arbitrary key/value pairs (args) which can be referenced from the msg string using placeholders
• https://learn.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-8.0#log-scopes It appears that .NET logging also supports arbitrary key/value pairs
• https://man.archlinux.org/man/systemd.journal-fields.7 systemd makes use of arbitrary key/value pairs (some keys are common, but apps may define custom ones)
• https://github.com/NLog/NLog/wiki/How-to-use-structured-logging#why-structured-logging Above-mentioned .NET page mentions this framework as an example for structured logging. On their wiki page they summarize some benefits of structured/semantic logging

Even if wasi:config/runtime could be used to tell the runtime how to interpret a log message exactly, I don't see an easy way to regain key/value pairs from a log sent via wasi-logging/logging. Would you expect that guests pass data encode as JSON within the message string and communicate the fact (that the message is JSON for the consumer to parse) using context and/or wasi:config/runtime?

[ricochet]

Oh! I understand what you meant now. Yes, key/value pairs are the biggest thing I personally want to see changed in this API. This allows for structured logging support that generally most modern languages are moving towards.

[Felix-El]

Maybe context itself is the first candidate to be part of that key/value map for it is not a universally required attribute (though not uncommon). The documentation for the K/V map should then probably act as sort-of-authority and state that the key context is well-known and serves a certain purpose (much like port numbers are managed by IANA). Possibly one could also prefix curated keys with std. or wasi. to highlight that semantics are documented.

This is a best-effort approach to have people align on the same keys unless they have really special needs, in which case they may file a PR to align on the use of their newly-proposed keys, too.

I believe this leaves the door open for many of the different perspectives people have on logging (from low-level like per-process through high-level like OS event logging) without feeling too unnatural to the different parties. (For instance I was initially wondering how to convey the arguments I need but is not specified in the interface while also trying to avoid having to provide dummy values for specified arguments I personally don't use such as context).

This might be even sufficient to transport traces i.e. for OpenTelemetry with some transformation though I'm not an expert in that area.

[jtsylve]

I agree, some (optional) structured logging capabilities would be ideal.