├── .github └── workflows │ └── main.yml ├── LICENSE.md ├── README.md ├── ROADMAP.md ├── imports.md ├── justfile ├── meetings ├── 2024 │ ├── 2024-01-31.md │ ├── 2024-02-14.md │ ├── 2024-02-28.md │ ├── 2024-09-11.md │ ├── 2024-09-25.md │ ├── 2024-10-09.md │ └── 2024-10-23.md ├── 2025 │ └── 2025-01-15.md └── TEMPLATE.md ├── test └── README.md └── wit ├── deps.lock ├── deps.toml ├── deps ├── clocks │ ├── monotonic-clock.wit │ ├── timezone.wit │ ├── wall-clock.wit │ └── world.wit ├── io │ ├── error.wit │ ├── poll.wit │ ├── streams.wit │ └── world.wit └── logging │ ├── logging.wit │ └── world.wit ├── tracer.wit └── world.wit /.github/workflows/main.yml: -------------------------------------------------------------------------------- 1 | name: CI 2 | on: 3 | push: 4 | branches: [main] 5 | pull_request: 6 | branches: [main] 7 | 8 | jobs: 9 | abi-up-to-date: 10 | name: Check ABI files are up-to-date 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/checkout@v3 14 | - uses: WebAssembly/wit-abi-up-to-date@v22 15 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | Copyright © 2019-2023 the Contributors to the WASI Specification, published 2 | by the [WebAssembly Community Group][cg] under the 3 | [W3C Community Contributor License Agreement (CLA)][cla]. A human-readable 4 | [summary][summary] is available. 5 | 6 | [cg]: https://www.w3.org/community/webassembly/ 7 | [cla]: https://www.w3.org/community/about/agreements/cla/ 8 | [summary]: https://www.w3.org/community/about/agreements/cla-deed/ 9 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # WASI Observe World 2 | 3 | A proposed [WebAssembly System Interface](https://github.com/WebAssembly/WASI) API. 4 | 5 | ### Current Phase 6 | 7 | WASI Observe is currently in [Phase 1]. 8 | 9 | [Phase 1]: https://github.com/WebAssembly/WASI/blob/42fe2a3ca159011b23099c3d10b5b1d9aff2140e/docs/Proposals.md#phase-1---feature-proposal-cg 10 | 11 | ### Meetings 12 | 13 | Meetings are **fortnightly** (held every other week, starting on `2024-W05` 14 | (`2024 Jan 31`) on **Wednesdays at UTC 16:00**. 15 | 16 | Contact [**@calebschoepp**](https://github.com/calebschoepp) via `caleb.schoepp 17 | at fermyon dot com` to request an invite. Participants must be W3C [WebAssembly 18 | CG members](https://www.w3.org/community/webassembly/). 19 | 20 | ### Roadmap 21 | 22 | - [Phase 1](./ROADMAP.md) 23 | 24 | ### Champions 25 | 26 | - Caleb Schoepp ([Fermyon][fermyon]) 27 | 28 | [fermyon]: https://www.fermyon.com/ 29 | [dylibso]: https://dylibso.com/ 30 | 31 | ### Portability Criteria 32 | 33 | TODO before entering Phase 2. 34 | 35 | ## Table of Contents 36 | 37 | - [Introduction](#introduction) 38 | - [An aside](#an-aside-about-the-origin-of-the-proposal) 39 | - [Goals](#goals) 40 | - [Technical Values](#technical-values) 41 | - [User Stories](#user-stories) 42 | - [A Programmer is Required to Implement O11Y Instrumentation](#a-programmer-is-required-to-implement-o11y-instrumentation) 43 | - [An O11Y Vendor Evaluates Supporting Wasm Components](#an-o11y-vendor-evaluates-supporting-wasm-components) 44 | - [A Site Reliability Engineer Considers Supporting Wasm Components](#a-site-reliability-engineer-considers-supporting-wasm-components) 45 | - [Non-goals](#non-goals) 46 | - [API walk-through](#api-walk-through) 47 | - [Stakeholder Interest & Feedback](#stakeholder-interest--feedback) 48 | - [References & acknowledgements](#references--acknowledgements) 49 | 50 | ### Introduction 51 | 52 | WASI Observe exposes observability ("o11y") tracing, logging, and metrics 53 | interfaces to Wasm components. The primary motivation of the interface is to 54 | allow for manual and automatic instrumentation of components that consume the 55 | interface (**"guests"**), while allowing components instances that implement 56 | the interface (**"hosts"**) sufficient context to ship the produced data to an 57 | o11y **vendor** (DataDog, Honeycomb.) The protocol used by the host to 58 | communicate with the vendor is an implementation detail of the providing 59 | component. 60 | 61 | #### An aside about the origin of the proposal 62 | 63 | Dylibso extracted the interface proposal [from an effort][dylibso-pr] to port 64 | Dylibso's Observe-SDK bindings, which target Wasm Core Modules, to the Wasm 65 | Component Model; the initial proposal reflects those origins. In particular: 66 | 67 | - The host is expected to track and maintain span state for guests. 68 | - The interface is isomorphic across components and core modules. A runtime 69 | implementing the host interface only needs to implement the interface once. 70 | 71 | These properties are not set in stone! This proposal is a work in progress and 72 | we're looking for interested parties to help us set technical values and direction 73 | starting in Jan. 74 | 75 | [dylibso-pr]: https://github.com/dylibso/observe-sdk/pull/128 76 | 77 | ### Goals 78 | 79 | #### Technical Values 80 | 81 | - WASI Observe is a pipe. The interesting O11Y work happens at either end of 82 | this pipe: at guest instrumentation or host collection. 83 | - Using WASI Observe should be as transparent as possible for authors of guest 84 | applications. 85 | - TKTK(proposed value)?: Target the OTel specification as the "base layer" of functionality. 86 | 87 | --- 88 | 89 | #### User Stories 90 | 91 | ##### A Programmer is Required to Implement O11Y Instrumentation 92 | 93 | A programmer working at a company goes to implement a new service. The Site 94 | Reliability Engineering function of the engineering department requires that 95 | new services be instrumented using standard tooling. The programmer installs an 96 | instrumentation package using the appropriate package manager (`npm`, `cargo`, 97 | `curl -o`), configures the package according to the documentation, and pushes 98 | the code. 99 | 100 | The instrumentation Just Works (TM.) In this scenario, it is not necessary for 101 | the programmer to be aware that their service is compiled to a Wasm component, 102 | or to make any adjustments to accommodate the compile target. 103 | 104 | ##### An O11Y Vendor Evaluates Supporting Wasm Components 105 | 106 | A hypothetical O11Y Vendor, Omni Consumer Products ("OCP"), evaluates 107 | supporting Wasm Components as a target. OCP maintains instrumentation libraries 108 | across several language platforms: JavaScript, Ruby, Golang, Rust, Python, and 109 | others; collocated collector services meant to be run by their customers; 110 | short- and long-term data storage; and visualization dashboards. 111 | 112 | OCP takes particular care to ensure that on-site collector services and 113 | instrumentation libraries introduce as little resource overhead as possible, 114 | both in terms of CPU time and memory use. 115 | 116 | In order to support Wasm Components across their language platform offerings, 117 | OCP are able to introduce low-cost checks for the availability of WASI Observe 118 | functions at initialization time. Where the Observe functions are available 119 | they can be used to intercept incoming domain objects (spans, logs, metrics) 120 | with minimal modification to the incoming data. 121 | 122 | Looking forward, OCP is considering compiling their on-site collector service 123 | to a Wasm component to more directly intercept and export o11y data off-site 124 | using fewer resources with a better security profile. 125 | 126 | Buoyed by the success of this approach, OCP is considering automatic 127 | instrumentation of components at component instantiation points. 128 | 129 | ##### A Site Reliability Engineer Considers Supporting Wasm Components 130 | 131 | A Site Reliability Engineering engineer ("SRE") working at a large software as 132 | a service company evaluates whether supporting Wasm components is feasible at 133 | this time. The SRE is responsible for the operation and maintenance of several 134 | production services. Before adopting a new platform target, the SRE considers 135 | the telemetry that platform makes available. 136 | 137 | Having considered the telemetry available through the WASI observe tooling, the 138 | SRE determines that the Wasm component model is an acceptable platform target. 139 | 140 | ##### A Programmer Wants Automatic Instrumentation Of Their Component 141 | 142 | A programmer is having trouble tracking down a problem in their component related 143 | to imports and exports during development. Without bringing in specific libraries 144 | to set up spans and trace contexts, they wish to export a trace of each invoked 145 | export and import during the lifetime of that component. 146 | 147 | ### Non-goals 148 | 149 | - TKTK 150 | 151 | ### API walk-through 152 | 153 | The full API documentation can be found [here](imports.md). 154 | 155 | ### Stakeholder Interest & Feedback 156 | 157 | TODO before entering Phase 3. 158 | 159 | [This should include a list of implementers who have expressed interest in implementing the proposal] 160 | 161 | ### References & acknowledgements 162 | 163 | Many thanks for valuable feedback and advice from: 164 | 165 | - [Person 1] 166 | - [Person 2] 167 | - [etc.] 168 | -------------------------------------------------------------------------------- /ROADMAP.md: -------------------------------------------------------------------------------- 1 | # Phase 1 Roadmap 2 | 3 | We intend to work in a "demo-oriented" fashion to build a corpus of working 4 | code. Changes to the spec should be reflected in the demos. We should have a 5 | demo that proves we support each user story listed in the 6 | [README](./README.md#user-stories). 7 | 8 | ## Demo 0 9 | 10 | A component (implemented in any language) uses high-level span functions to 11 | send basic telemetry information to a host (implemented in any language.) The 12 | host sends the telemetry information (spans and basic logs) to a Jaegar stack. 13 | The component is activated by an external request; for example, an incoming 14 | http request. The demo should run in Docker containers, possibly orchestrated 15 | via `docker-compose` or similar. 16 | 17 | Once completed, find the demo in the `./demos/00-basic` directory of this 18 | repository. 19 | 20 | **Stretch Goals:** 21 | 22 | - Run two components in order to test distributed tracing. 23 | 24 | **Scope:** 25 | 26 | - Add a `context` parameter to the WIT and use it in this demo. It doesn't have 27 | to be fully designed yet. 28 | - (See discussion [here](https://github.com/WebAssembly/wasi-observe/issues/4).) 29 | - Use the high-level `wasi-observe` interface (`span-{enter,exit}` functions, 30 | `log`.) 31 | - We're currently evaluating a more complete representation of Otel in WIT. 32 | Backporting that representation existing demos will help prove it out. 33 | - We may wish to make an early decision about our use of `wasi-logging`. 34 | - (See discussion [here](https://github.com/WebAssembly/wasi-observe/issues/7).) 35 | 36 | **Timeline:** 37 | 38 | - Open-ended, but ideally before mid-March. 39 | -------------------------------------------------------------------------------- /imports.md: -------------------------------------------------------------------------------- 1 |

World imports

2 | 11 |

Import interface wasi:logging/logging

12 |

WASI Logging is a logging API intended to let users emit log messages with 13 | simple priority levels and context values.

14 |
15 |

Types

16 |

enum level

17 |

A log level, describing a kind of message.

18 |
Enum Cases
19 | 48 |
49 |

Functions

50 |

log: func

51 |

Emit a log message.

52 |

A log message has a level describing what kind of message is being 53 | sent, a context, which is an uninterpreted string meant to help 54 | consumers group similar messages, and a string containing the message 55 | text.

56 |
Params
57 | 62 |

Import interface wasi:clocks/wall-clock@0.2.1

63 |

WASI Wall Clock is a clock API intended to let users query the current 64 | time. The name "wall" makes an analogy to a "clock on the wall", which 65 | is not necessarily monotonic as it may be reset.

66 |

It is intended to be portable at least between Unix-family platforms and 67 | Windows.

68 |

A wall clock is a clock which measures the date and time according to 69 | some external reference.

70 |

External references may be reset, so this clock is not necessarily 71 | monotonic, making it unsuitable for measuring elapsed time.

72 |

It is intended for reporting the current date and time for humans.

73 |
74 |

Types

75 |

record datetime

76 |

A time and date in seconds plus nanoseconds.

77 |
Record Fields
78 | 82 |
83 |

Functions

84 |

now: func

85 |

Read the current value of the clock.

86 |

This clock is not monotonic, therefore calling this function repeatedly 87 | will not necessarily produce a sequence of non-decreasing values.

88 |

The returned timestamps represent the number of seconds since 89 | 1970-01-01T00:00:00Z, also known as POSIX's Seconds Since the Epoch, 90 | also known as Unix Time.

91 |

The nanoseconds field of the output is always less than 1000000000.

92 |
Return values
93 | 96 |

resolution: func

97 |

Query the resolution of the clock.

98 |

The nanoseconds field of the output is always less than 1000000000.

99 |
Return values
100 | 103 |

Import interface wasi:observe/tracer

104 |
105 |

Types

106 |

type datetime

107 |

datetime

108 |

109 | #### `resource span` 110 |

Represents a unit of work or operation.

111 |

enum span-kind

112 |

Describes the relationship between the Span, its parents, and its children in a trace.

113 |
Enum Cases
114 | 136 |

variant status

137 |

The status of a span.

138 |
Variant Cases
139 | 153 |

type key

154 |

string

155 |

The key part of attribute `key-value` pairs. 156 |

variant value

157 |

The value part of attribute key-value pairs.

158 |
Variant Cases
159 | 193 |

record key-value

194 |

A key-value pair describing an attribute.

195 |
Record Fields
196 | 206 |

type trace-id

207 |

string

208 |

The trace that this `span-context` belongs to. 209 |

16 bytes encoded as a hexadecimal string.

210 |

type span-id

211 |

string

212 |

The id of this `span-context`. 213 |

8 bytes encoded as a hexadecimal string.

214 |

flags trace-flags

215 |

Flags that can be set on a span-context.

216 |
Flags members
217 | 221 |

type trace-state

222 |

trace-state

223 |

Carries system-specific configuration data, represented as a list of key-value pairs. `trace-state` allows multiple tracing systems to participate in the same trace. 224 |

If any invalid keys or values are provided then the trace-state will be treated as an empty list.

225 |

record span-context

226 |

Identifying trace information about a span that can be serialized and propagated.

227 |
Record Fields
228 | 250 |

record link

251 |

Describes a relationship to another span.

252 |
Record Fields
253 | 263 |

record start-options

264 |

Configuration for starting a span.

265 |
Record Fields
266 | 288 |
289 |

Functions

290 |

start: func

291 |

Starts a new span with the given name and options.

292 |
Params
293 | 297 |
Return values
298 | 301 |

[method]span.span-context: func

302 |

Get the span-context for this span.

303 |
Params
304 | 307 |
Return values
308 | 311 |

[method]span.is-recording: func

312 |

Returns true when the data provided to this span is captured in some form. If it returns false then any data provided is discarded.

313 |
Params
314 | 317 |
Return values
318 | 321 |

[method]span.set-attributes: func

322 |

Set attributes of this span.

323 |

If a key already exists for an attribute of the Span it will be overwritten with the corresponding new value.

324 |
Params
325 | 329 |

[method]span.add-event: func

330 |

Adds an event with the provided name at the curent timestamp.

331 |

Optionally an alternative timestamp may be provided. You may also provide attributes of this event.

332 |
Params
333 | 339 |

[method]span.add-link: func

340 |

Associates this span with another.

341 |
Params
342 | 346 |

[method]span.set-status: func

347 |

Override the default span status, which is unset.

348 |
Params
349 | 353 |

[method]span.update-name: func

354 |

Updates the span name.

355 |
Params
356 | 360 |

[method]span.end: func

361 |

Signals that the operation described by this span has now ended.

362 |

If a timestamp is not provided then it is treated equivalent to passing the current time. Dropping this resource is the equivalent of calling end(none).

363 |
Params
364 | 368 | -------------------------------------------------------------------------------- /justfile: -------------------------------------------------------------------------------- 1 | default: 2 | @just --choose 3 | 4 | _prepare: 5 | #!/bin/bash 6 | if ! &>/dev/null which cargo; then 7 | >&2 echo 'Install Rust: https://rustup.rs/' 8 | exit 1 9 | fi 10 | 11 | if ! &>/dev/null which wit-deps; then 12 | cargo install wit-deps-cli@0.3.4 13 | fi 14 | 15 | if ! &>/dev/null which wit-bindgen; then 16 | cargo install wit-bindgen-cli@0.30.0 17 | fi 18 | 19 | build: 20 | wit-bindgen markdown wit --html-in-md 21 | -------------------------------------------------------------------------------- /meetings/2024/2024-01-31.md: -------------------------------------------------------------------------------- 1 | ## Agenda: Jan 31 WASI Observe Video call 2 | 3 | - **Where**: zoom.us 4 | - **When**: Jan 31 2024, 16:00-17:00 UTC 5 | - **Contact**: 6 | - Name: Chris Dickinson 7 | - Email: chris@dylibso.com 8 | 9 | ## Logistics 10 | 11 | The meeting will be on a zoom.us video conference. 12 | 13 | ## Agenda items 14 | 15 | 1. [Chris Dickinson]: Discuss design values and goals, starting from the README; are we aligned? 16 | 1. [Chris Dickinson]: WASI proposal process: what to expect, upcoming dates, Phase 1 presentation & vote, etc. 17 | 1. [Chris Dickinson]: Bookkeeping -- do we want to plan on weekly or fortnightly meetings? Is this time slot okay? Do we want a chat channel someplace? 18 | 19 | ## Minutes 20 | 21 | ### Attendees 22 | 23 | - [**@brooksmtownsend**][brooksmtownsend], Cosmonic 24 | - [**@chrisdickinson**][chrisdickinson], Dylibso; moderating 25 | - [**@endocrimes**][endocrimes], Fermyon 26 | - [**@walther**][walther] 27 | 28 | ### Action items 29 | 30 | - [**@brooksmtownsend**][brooksmtownsend] to PR a user story for supporting automatic component instrumentation. 31 | - [**@chrisdickinson**][chrisdickinson] to reach out to wasi-logging to see if we can help with that effort 32 | - [**@endocrimes**][endocrimes] to look into surveying tracing functionality. 33 | - open action item: investigate adding context parameter to `span-{enter,exit,tags}`. 34 | - [**@chrisdickinson**][chrisdickinson] to file an issue so we can start a discussion 35 | - [**@chrisdickinson**][chrisdickinson] to schedule the next meeting (same time / day of week) 36 | 37 | [brooksmtownsend]: https://github.com/brooksmtownsend 38 | [endocrimes]: https://github.com/endocrimes 39 | [walther]: https://github.com/walther 40 | [chrisdickinson]: https://github.com/chrisdickinson 41 | -------------------------------------------------------------------------------- /meetings/2024/2024-02-14.md: -------------------------------------------------------------------------------- 1 | ## Agenda: Feb 14 WASI Observe Video call 2 | 3 | - **Where**: zoom.us 4 | - **When**: Feb 14 2024, 16:00-16:30 UTC 5 | - **Contact**: 6 | - Name: Chris Dickinson 7 | - Email: chris@dylibso.com 8 | 9 | ## Logistics 10 | 11 | The meeting will be on a zoom.us video conference. 12 | 13 | ## Agenda items 14 | 15 | 1. [Chris Dickinson][chrisdickinson]: WASI Phase 1! Discuss what comes next. 16 | 1. [Chris Dickinson][chrisdickinson]: Context param 17 | - https://github.com/WebAssembly/wasi-observe/issues/4 18 | 19 | ## Minutes 20 | 21 | - [**@chrisdickinson**][chrisdickinson] we have interest from new folks from the WASI meeting 22 | - luke from fastly, matthew from f5 23 | - [**@chrisdickinson**][chrisdickinson] general reminder 24 | - please add yourselves to the champions list on the README! 25 | - [**@chrisdickinson**][chrisdickinson] we're in phase 1! what does that mean? 26 | - well, pretty much what we talked about: now we do the work to get to phase 2 (and beyond) 27 | - practicality, portability, and testing criteria 28 | - we may need to lean on luke (or others) for more definition on the expectations around portability and testing criteria 29 | - practicality 30 | - I'd suggest we start here: I propose we aim for a demo component and host that exercise 31 | the user stories 32 | - can we componentize an otel rust app? js? python? 33 | - how do we test the "vendor can hide the implementation" bit of this? 34 | - [**@brooksmtownsend**][brooksmtownsend]: we might want to start by having a simple trigger (an incoming wasi-http request) call 35 | out into the interface directly. It can be tough to navigate the rust tracing even without making significant edits to it. 36 | - [**@chrisdickinson**][chrisdickinson]: Yeah, I'm kind of trying to front-load a question for the registry effort with the "vendor can hide the implementation" 37 | question -- how does a 3rd party package introduce new host binding requirements? 38 | - [**@chrisdickinson**][chrisdickinson]: do we have any takers on the first demo? 39 | - [general hesitance] 40 | - to be clear, this definitely doesn't have to be done before the next meeting 41 | - this might be a sign we need more info 42 | - where should the host send observability info to start? 43 | - [**@endocrimes**][endocrimes]: jaegar; it's easy to dockerize an entire jaegar stack 44 | - [**@walther**][walther]: it'd be great to make the demo entirely dockerized & easy to run for demostration purposes 45 | - [**@walther**][walther]: [CD check me on this! I might have attributed the wrong person]; could we have two components communicate & send spans with latency? 46 | - [**@endocrimes**][endocrimes]: once we have one component sending data, it should be straightforward to have two [CD paraphrase!] 47 | - [**@walther**][walther]: it'd be interesting to pull in some other WASI apis to get a waterfall -- fs, for example? 48 | - [**@chrisdickinson**][chrisdickinson]: okay, so we send the host to jaegar; are there any requirements on the component? language choice? 49 | - [general agreement that it's implementer's choice] 50 | - [**@endocrimes**][endocrimes]: (late join due to coffee mishap); status update 51 | - working on a full Otel WIT interface 52 | - it's long -- 100s of lines without doc comments already 53 | - but on the other hand, it's complete -- it represents events 54 | - working towards a demo, but time is the constraint 55 | - [**@chrisdickinson**][chrisdickinson]: would you be okay with sharing the WIT file early as an issue? 56 | - [**@endocrimes**][endocrimes]: sure! 57 | - [**@chrisdickinson**][chrisdickinson]: Adding context parameter to span/log functions 58 | - https://github.com/WebAssembly/wasi-observe/issues/4 59 | - [**@brooksmtownsend**][brooksmtownsend]: reconstituting state: are we moving forward with our own logging functions? 60 | - [**@chrisdickinson**][chrisdickinson]: wasi-logging is, as I understand it, kind of floating in space right now. wasi-http/cloud was going to use it 61 | but opted for stdout/err instead. So they may be amenable to changes / we might be able to help steer it in a direction that's useful for observability purposes. 62 | - Logging uses a string; but it strikes me that that might be expensive to copy. 63 | - [**@brooksmtownsend**][brooksmtownsend]: yeah, I think logging went this direction to hedge their bets. I'd like to eventually use a full-fledged type once we have more info. 64 | - Ideally I think we could get away with an opaque thread id 65 | - I'd like to look into using a resource, but I'm not totally up on resource use yet. 66 | - there might be reasons _not_ to use resources -- a parent cannot outlive a child, for example 67 | - [**@chrisdickinson**][chrisdickinson]: do we need to include this context param in the first demo? 68 | - [**@endocrimes**][endocrimes]: ideally yes. it won't make much sense to an otel person without it. 69 | - Meeting cadence check 70 | - [**@chrisdickinson**][chrisdickinson]: is 30 minutes / fortnightly okay with folks? 71 | - [general nodding] 72 | 73 | ### Attendees 74 | 75 | - [**@brooksmtownsend**][brooksmtownsend], Cosmonic 76 | - [**@chrisdickinson**][chrisdickinson], Dylibso; moderating 77 | - [**@endocrimes**][endocrimes], Fermyon 78 | - [**@walther**][walther] 79 | 80 | ### Action items 81 | 82 | - [**@chrisdickinson**][chrisdickinson]: Post demo 1 script as PR 83 | - [**@endocrimes**][endocrimes]: (in the short-term) Post WIP OTel WIT as issue 84 | - [**@endocrimes**][endocrimes]: (longer-term, time permitting) Post Otel demo using OTel WIT 85 | 86 | [brooksmtownsend]: https://github.com/brooksmtownsend 87 | [endocrimes]: https://github.com/endocrimes 88 | [walther]: https://github.com/walther 89 | [chrisdickinson]: https://github.com/chrisdickinson 90 | -------------------------------------------------------------------------------- /meetings/2024/2024-02-28.md: -------------------------------------------------------------------------------- 1 | ## Agenda: Feb 28 WASI Observe Video call 2 | 3 | - **Where**: zoom.us 4 | - **When**: Feb 28 2024, 16:00-16:30 UTC 5 | - **Contact**: 6 | - Name: Chris Dickinson 7 | - Email: chris@dylibso.com 8 | 9 | ## Logistics 10 | 11 | The meeting will be on a zoom.us video conference. 12 | 13 | ## Attendees 14 | 15 | - [Chris][CD] (moderating, notetaking) 16 | - [Danielle] 17 | - [Caleb] 18 | - [Matthew] 19 | - [JC] 20 | - [Luke] 21 | - [Brooks] 22 | - [Walther] 23 | 24 | ## Agenda items 25 | 26 | - [CD]: Welcome new members! 27 | - [CD]: Roundtable updates 28 | - [Danielle]: tracing [WIT draft PR](https://github.com/WebAssembly/wasi-observe/pull/12/files) 29 | 30 | ## Minutes 31 | 32 | - [CD]: Welcome new members! 33 | - [CD]: Roundtable updates 34 | - [Danielle]: tracing [WIT draft PR](https://github.com/WebAssembly/wasi-observe/pull/12/files) 35 | - added readback (resources) and flushing (records) 36 | - [JC]: [cd: tktk please correct me] discussion of whether or not we want readback 37 | - [Danielle]: [cd tktk] 38 | - [JC]: Propose moving to issue 39 | - [JC]: set-attribute has a lot of options in otel; strings, booleans, ints, we should think about whether we want to support the full set (or a useful subset) 40 | - [Danielle]: any way to express this in WIT? 41 | - [Luke]: brute-force via multiple methods 42 | - [JC]: support for submitting an event with a timestamp, vs using the host 43 | - [Danielle]: host is your tracing provider, the equiv of your otel provider, which manages timestamps for you 44 | - [JC]: thinking of cases where clients provide you back server time 45 | - [CD]: gesturing at the goal of being a pipe 46 | - [Danielle]: I think most people will use the read-only spans for these purposes 47 | - [CD]: discussion of using the span record to support node-style "oops this span belongs to a different continuation" situations 48 | - [JC]: started working in php a long time ago, supported all frameworks for a long time; but then react-php came out. assumption was that we could access the span because it would be thread-local; when we attempted to instrument, we needed to pass a context 49 | - we explored two things: a context object; passing that as the first arg so you could access the span from the context 50 | - another model: you only store the id 51 | - if you don't have readback, you only need the id – all of the attrs are setters 52 | - you don't need to keep the state, you just keep the id – host holds the state by id 53 | 54 | ### Action items 55 | 56 | - New folks -- please go read the user stories on the readme and open issues if you find anything 57 | that strikes you as incorrect! 58 | - Anyone who is interested, please try implementing [roadmap demo 0](https://github.com/WebAssembly/wasi-observe/blob/main/ROADMAP.md#demo-0) 59 | - multiple implementations are encouraged! 60 | - Everyone -- we're going to try out github discussions for our communication channel 61 | - Review the [WIT draft PR](https://github.com/WebAssembly/wasi-observe/pull/12/files) 62 | 63 | [Danielle]: https://github.com/endocrimes 64 | [JC]: https://github.com/jcchavezs 65 | [CD]: https://github.com/chrisdickinson 66 | [Caleb]: https://github.com/calebschoepp 67 | [Matthew]: https://github.com/f5yacobucci 68 | [Luke]: https://github.com/lukewagner 69 | [Brooks]: https://github.com/brooksmtownsend 70 | [Walther]: https://github.com/walther 71 | -------------------------------------------------------------------------------- /meetings/2024/2024-09-11.md: -------------------------------------------------------------------------------- 1 | ## Agenda: Sep 11 WASI Observe Video call 2 | 3 | - **Where**: zoom.us 4 | - **When**: Sep 11 2024, 15:00-15:30 UTC 5 | - **Contact**: 6 | - Name: Caleb Schoepp 7 | - Email: caleb.schoepp@fermyon.com 8 | 9 | ## Logistics 10 | 11 | The meeting will be on a zoom.us video conference. 12 | 13 | ## Agenda items 14 | 15 | 1. [**@calebschoepp**][cs]: Announce Chris Dickinson stepping down from champion role and Caleb filling in. 16 | 1. [**@calebschoepp**][cs]: Talk about current PR for [tracing](https://github.com/WebAssembly/wasi-observe/pull/15). 17 | 18 | ## Minutes 19 | 20 | - [**@scb01**][sb]: It was pretty confusing that there were so many files changed in the PR. 21 | - [**@calebschoepp**][cs]: I'll split it into two commits. 22 | - [**@scb01**][sb]: We should consider not providing functionality to provide timestamps to start and end. This is simpler and would remove a dependency on wasi clocks. 23 | - [**@calebschoepp**][cs]: I like removing the dependency but I'm not sure what the other downsides are. 24 | - [**@scb01**][sb]: I'll make this as a question on the PR. 25 | - [**@scb01**][sb]: Everything else looked good to me. Couple minor things I'll raise. 26 | - [**@scb01**][sb]: I think you struck a reasonable balance of mirroring the OTel spec, but not being beholden to it. Maybe some reservations about linking and explicitly setting parents. 27 | - [**@calebschoepp**][cs]: I expect to receive a lot more feedback upstream about how this fits into composition and async with regards to the component model. 28 | 29 | ### Attendees 30 | 31 | - [**@scb01**][sb] (Shekar Bommas), Microsoft 32 | - [**@calebschoepp**][cs] (Caleb Schoepp), Fermyon; moderating 33 | 34 | ### Action items 35 | 36 | - [**@calebschoepp**][cs] to make new meeting invite. 37 | - [**@scb01**][sb] to post comments. 38 | 39 | [cs]: https://github.com/calebschoepp 40 | [sb]: https://github.com/scb01 41 | -------------------------------------------------------------------------------- /meetings/2024/2024-09-25.md: -------------------------------------------------------------------------------- 1 | ## Agenda: Sep 25 WASI Observe Video call 2 | 3 | - **Where**: zoom.us 4 | - **When**: Sep 25 2024, 15:00-15:30 UTC 5 | - **Contact**: 6 | - Name: Caleb Schoepp 7 | - Email: caleb.schoepp@fermyon.com 8 | 9 | ## Logistics 10 | 11 | The meeting will be on a zoom.us video conference. 12 | 13 | ## Agenda items 14 | 15 | 1. [**@calebschoepp**][cs]: Planning to bring an update of WASI Observe to the subgroup. 16 | 1. [**@calebschoepp**][cs]: Starting work on a metrics implementation. 17 | 1. [**@calebschoepp**][cs]: Looking for a list of tracing systems other than OTel. 18 | 19 | ## Minutes 20 | 21 | - [**@scb01**][sb]: Happy to look over slides that you'll bring to the subgroup. 22 | - [**@calebschoepp**][cs]: I've got a little bit of metrics WIT to share. 23 | - [**@scb01**][sb]: I think that it is ideal for the user to not need to initialize the instrument. It's simpler, and also prevents them from having to pass the instrument around the whole program. We could back it with a simple map of names to instruments in the host. We could provide an option for them to initialize the instrument with a description and unit, but otherwise could just use sane defaults. 24 | - [**@calebschoepp**][cs]: Looking to understand what other tracing systems than OTel and Rust tokio-tracing exist. 25 | - [**@scb01**][sb]: OTel, Jaeger Opentrace (maybe merged into OTel now). 26 | - [**@calebschoepp**][cs]: If there is significant desire to make WASI Observe super broad than I think we should consider narrowing the scope to be WASI OTel. 27 | - [**@scb01**][sb]: I like the clarity of WASI OTel but I don't like that it would tie us to their pace of iteration. 28 | 29 | ### Attendees 30 | 31 | - [**@scb01**][sb] (Shekar Bommas), Microsoft 32 | - [**@calebschoepp**][cs] (Caleb Schoepp), Fermyon; moderating 33 | 34 | ### Action items 35 | 36 | - [**@calebschoepp**][cs] to add Shekar to meeting invite. 37 | - [**@scb01**][sb] to share draft metrics WIT with Caleb. 38 | - [**@scb01**][sb] to do some research on what other tracing systems there are. 39 | 40 | [cs]: https://github.com/calebschoepp 41 | [sb]: https://github.com/scb01 42 | -------------------------------------------------------------------------------- /meetings/2024/2024-10-09.md: -------------------------------------------------------------------------------- 1 | ## Agenda: Oct 9 WASI Observe Video call 2 | 3 | - **Where**: zoom.us 4 | - **When**: Oct 9 2024, 15:00-15:30 UTC 5 | - **Contact**: 6 | - Name: Caleb Schoepp 7 | - Email: caleb.schoepp@fermyon.com 8 | 9 | ## Logistics 10 | 11 | The meeting will be on a zoom.us video conference. 12 | 13 | ## Agenda items 14 | 15 | No pre-planned agenda. 16 | 17 | ## Minutes 18 | 19 | - [**@brooksmtownsend**][bt]: I like mapping it to OTel 20 | - [**@brooksmtownsend**][bt]: Addresses a few comments from the PR 21 | - [**@brooksmtownsend**][bt]: Doesn't want to bikeshed names but maybe this should be called otel 22 | - [**@brooksmtownsend**][bt]: I think a mechanism to start a span as a new root is good 23 | - [**@brooksmtownsend**][bt]: I think the resource thing is a good idea 24 | - [**@brooksmtownsend**][bt]: Might make sense for start to return a result in the case where tracing is turned off 25 | - [**@calebschoepp**][cs]: I feel like if tracing is off they could all just be no-ops 26 | - [**@brooksmtownsend**][bt]: Suggest we add a get current context function 27 | - [**@calebschoepp**][cs]: We used to have functionality for that 28 | - [**@calebschoepp**][cs]: One weird thing was that making span context's could fail and I didn't know where to bubble up that failure 29 | - [**@brooksmtownsend**][bt]: Implementing guest libraries will tell us a lot about how we should do that 30 | - [**@brooksmtownsend**][bt]: It could be useful to have a notion of a trace resource 31 | - [**@calebschoepp**][cs]: I have concerns around making a trace resource 32 | - [**@brooksmtownsend**][bt]: My main goal is that I want guest applications to be able to use otel libraries 33 | - [**@calebschoepp**][cs]: We should probably call this wasi:otel or ba:otel 34 | - [**@brooksmtownsend**][bt]: I think that it might actually belong in wasi 35 | - [**@brooksmtownsend**][bt]: I think that makes a lot of sense to call this wasi:otel and put trace, metric, and logging interfaces under it 36 | - [**@calebschoepp**][cs]: I care more about just traces and logs 37 | - [**@brooksmtownsend**][bt]: wasi logging is a fundamental thing 38 | 39 | ### Attendees 40 | 41 | - [**@brooksmtownsend**][bt] (Brooks Townsend), Cosmonic 42 | - [**@calebschoepp**][cs] (Caleb Schoepp), Fermyon; moderating 43 | 44 | ### Action items 45 | 46 | [cs]: https://github.com/calebschoepp 47 | [bt]: https://github.com/brooksmtownsend 48 | -------------------------------------------------------------------------------- /meetings/2024/2024-10-23.md: -------------------------------------------------------------------------------- 1 | ## Agenda: Oct 23 WASI Observe Video call 2 | 3 | - **Where**: zoom.us 4 | - **When**: Oct 23 2024, 15:00-15:30 UTC 5 | - **Contact**: 6 | - Name: Caleb Schoepp 7 | - Email: caleb.schoepp@fermyon.com 8 | 9 | ## Logistics 10 | 11 | The meeting will be on a zoom.us video conference. 12 | 13 | ## Agenda items 14 | 15 | No pre-planned agenda. 16 | 17 | ## Minutes 18 | 19 | - [**@brooksmtownsend**][bt]: I like mapping it to OTel 20 | - [**@brooksmtownsend**][bt]: Addresses a few comments from the PR 21 | - [**@brooksmtownsend**][bt]: Doesn't want to bikeshed names but maybe this should be called otel 22 | - [**@brooksmtownsend**][bt]: I think a mechanism to start a span as a new root is good 23 | - [**@brooksmtownsend**][bt]: I think the resource thing is a good idea 24 | - [**@brooksmtownsend**][bt]: Might make sense for start to return a result in the case where tracing is turned off 25 | - [**@calebschoepp**][cs]: I feel like if tracing is off they could all just be no-ops 26 | - [**@brooksmtownsend**][bt]: Suggest we add a get current context function 27 | - [**@calebschoepp**][cs]: We used to have functionality for that 28 | - [**@calebschoepp**][cs]: One weird thing was that making span context's could fail and I didn't know where to bubble up that failure 29 | - [**@brooksmtownsend**][bt]: Implementing guest libraries will tell us a lot about how we should do that 30 | - [**@brooksmtownsend**][bt]: It could be useful to have a notion of a trace resource 31 | - [**@calebschoepp**][cs]: I have concerns around making a trace resource 32 | - [**@brooksmtownsend**][bt]: My main goal is that I want guest applications to be able to use otel libraries 33 | - [**@calebschoepp**][cs]: We should probably call this wasi:otel or ba:otel 34 | - [**@brooksmtownsend**][bt]: I think that it might actually belong in wasi 35 | - [**@brooksmtownsend**][bt]: I think that makes a lot of sense to call this wasi:otel and put trace, metric, and logging interfaces under it 36 | - [**@calebschoepp**][cs]: I care more about just traces and logs 37 | - [**@brooksmtownsend**][bt]: wasi logging is a fundamental thing 38 | 39 | ### Attendees 40 | 41 | - [**@brooksmtownsend**][bt] (Brooks Townsend), Cosmonic 42 | - [**@calebschoepp**][cs] (Caleb Schoepp), Fermyon; moderating 43 | 44 | ### Action items 45 | 46 | [cs]: https://github.com/calebschoepp 47 | [bt]: https://github.com/brooksmtownsend 48 | -------------------------------------------------------------------------------- /meetings/2025/2025-01-15.md: -------------------------------------------------------------------------------- 1 | # Agenda: Jan 15 WASI Observe Video call 2 | 3 | - **Where**: zoom.us 4 | - **When**: Jan 15 2025, 16:00-16:30 UTC 5 | - **Contact**: 6 | - Name: Caleb Schoepp 7 | 8 | # Logistics 9 | 10 | The meeting will be on a zoom.us video conference. 11 | 12 | # Agenda items 13 | 14 | 1. Discuss current state of tracing proposal 15 | - Plans to move it to WASI OTel 16 | - Actual interface itself 17 | 1. *Add in agenda items here* 18 | 19 | # Minutes 20 | 21 | ## Attendees 22 | 23 | - [**@calebschoepp**][calebschoepp] 24 | 25 | ## Action items 26 | 27 | - [**@{calebschoepp}**][calebschoepp], Start figuring out a new proposal for `wasi:otel` 28 | 29 | ## Notes 30 | 31 | ### wasi-observe as a Canon builtin layer after discussions with Luke and others 32 | 33 | - Caleb: Discussions pointed to this likely slowing us down/being a bad idea for now, but maybe later 34 | - Concretely this means: 35 | - Switch from wasi-observe to wasi-otel 36 | - [wasi-observe PR #15](https://github.com/WebAssembly/wasi-observe/pull/15/files) should likely be owned 37 | - Victor: Rename to `wasi-otel`? 38 | - Caleb: Could rename it, but why not garbage collect while we're here 39 | - Victor: Ah we could try to make a new repository? 40 | - Caleb: Could move us back to phase 0, why not garbage collect 41 | - Victor: Probably important to propose the new interface as a different proposal since we need approval anyway 42 | - Victor: Existing proposal with a changed internal interface? 43 | - Victor: this probably won't work, as the internals are going to change too much 44 | - Concensus: Create a new proposal 45 | 46 | ### Tracing interface discussion 47 | 48 | - Caleb: What we have currently mirrors the interfaces pretty well, but when using from a language, there are other concepts involved (ex. a TracerProvider) 49 | - Caleb: Does it make sense to more closely replicate the OTEL spec and create objects (i.e. Tracer, TracerProvider) that *then* create spans? 50 | - Victor: Maybe a yes? Two ideas are probably important: 51 | - Do we want to mirror the interface closely 52 | - Threaded use cases 53 | - Could have a default tracer that is created, but you might want a tracer per-thread 54 | - Caleb: Mirror is probably the most compelling reason up front 55 | - Victor: Some languages won't use this right? 56 | - Caleb: Which wouldn't use this? 57 | - Victor: Rust's `tracing` crate? 58 | - Caleb: No the Rust crate does underneath have a Tracer in use 59 | - Victor: Ah OK if Rust is expecting to have the Tracer then we need this? 60 | - Caleb: But then do we need a `TracerProvider` resource? 61 | - Victor: Yes this is definitely what's confusing -- it's not clear that the provider itself is present 62 | - Tracer is just a language level construct 63 | - Caleb: Start could take some tracer metadata? 64 | - Victor: Tracer seems like it should be present, but TracerProvider maybe not, since it's essentially just a constructor, and the provider is 65 | - Cannot think of a use case 66 | - Caleb: What would a custom TracerProvider even mean? 67 | - Victor: Delayed? Backwards spans? Filtering? 68 | - Caleb: (Looking at the OTEL docs) it looks like separate configuration & span processors 69 | - Victor: most of the stuff should actualy happen at the language level (make a trace, make a span, etc) 70 | - Caleb: so we should be able to modify the language SDKs to 71 | - Victor: Maybe we shouldn't have a tracer (for the same reasons of TracerProvider), it should maybe just be trace creation/modification/etc 72 | - Caleb: Correction, you're saying "traces" but you mean spans right? 73 | - Victor: Yes, I think of them as "root spans" 74 | - Victor: The Trace ID exists, so maybe we should have something that is a trace 75 | - Caleb: Trace IDs are only tracked via the SpanContext, per the spec 76 | - Victor: Yes, but I think it should be recommended at the WASI level, even though it's just a tag on a Root span 77 | - The idea of doing operations on traces or having them managed by the host *might* be necessary 78 | - Caleb: Could you clarify? By "trace" do you mean that it's a distinct resource from the span? 79 | - Victor: I'm thinking -- if the host starts the root span, how would it give it to the component? 80 | - Caleb: Currently the component would call `start` and if you wanted to 81 | - Victor: Ah, is it in the `start-options` ? 82 | - Caleb: But this seems somewhat unrelated to whether we should have the Tracer or not? 83 | - Victor: what I'm thinking here is that `tracer` doesn't do anything you can't do with the `span` resource now. 84 | - It's possible that Tracer logic should live outside just like TracerProvider logic, 85 | - Maybe this is fine since we have `start-options`, and that should be in the span constructor. 86 | - Implementations for tracer operations should just do WASI things. 87 | - Caleb: Maybe it makes more sense to try to build something around this for Go and/or Rust 88 | - Victor: Yes -- not sure about my availability to pair but if you can do the Go version I can do the Rust version 89 | - Caleb: How to generate the bindings 90 | - Victor: Yeah you can use the wit-bindgen tooling for that! wit-bindgen-go has changed a bunch though 91 | 92 | [calebschoepp]: https://github.com/calebschoepp 93 | -------------------------------------------------------------------------------- /meetings/TEMPLATE.md: -------------------------------------------------------------------------------- 1 | # Agenda: {month} {day} WASI Observe Video call 2 | 3 | - **Where**: zoom.us 4 | - **When**: {month} {day} {year}, {start_time}-{end_time} UTC 5 | - **Contact**: 6 | - Name: {CONTACT_NAME} 7 | - Email: {CONTACT_EMAIL} 8 | 9 | # Logistics 10 | 11 | The meeting will be on a zoom.us video conference. 12 | 13 | # Agenda items 14 | 15 | 1. *Add in agenda items here* 16 | 17 | # Minutes 18 | 19 | ## Attendees 20 | 21 | - [**@{identifier}**][github-identifier], {company} 22 | 23 | ## Action items 24 | 25 | - [**@{identifier}**][github-identifier], {task that should be accomplished} 26 | 27 | ## Notes 28 | 29 | - Add notes here 30 | 31 | [github-identifier]: https://github.com/user 32 | -------------------------------------------------------------------------------- /test/README.md: -------------------------------------------------------------------------------- 1 | # Testing guidelines 2 | 3 | TK fill in testing guidelines 4 | 5 | ## Installing the tools 6 | 7 | TK fill in instructions 8 | 9 | ## Running the tests 10 | 11 | TK fill in instructions 12 | -------------------------------------------------------------------------------- /wit/deps.lock: -------------------------------------------------------------------------------- 1 | [clocks] 2 | url = "https://github.com/WebAssembly/wasi-clocks/archive/main.tar.gz" 3 | sha256 = "ea9d69ee803bc176e23e5268f5e24a2ac485dd1f62a0ab4c748e9d3f901f576f" 4 | sha512 = "5efc22927c46cd56c41e5549ec775561c7fac2ea0d365abc0b55396d9475a7c9f984077a81f84a44a726f1c008fd2fadbffffa4fa53ecd5fbfd05afd379ab428" 5 | deps = ["io"] 6 | 7 | [io] 8 | sha256 = "2a74bd811adc46b5a0f19827ddbde89870e52b17615f4d0873f06fd977250caf" 9 | sha512 = "94624f00c66e66203592cee820f80b1ba91ecdb71f682c154f25eaf71f8d8954197dcb64503bc21e72ed5e812af7eae876df47b7eb727b02db3a74a7ce0aefca" 10 | 11 | [logging] 12 | url = "https://github.com/WebAssembly/wasi-logging/archive/main.tar.gz" 13 | sha256 = "9676b482485bb0fd2751a390374c1108865a096b7037f4b5dbe524f066bfb06e" 14 | sha512 = "30a621a6d48a0175e8047c062e618523a85f69c45a7c31918da2b888f7527fce1aca67fa132552222725d0f6cdcaed95be7f16c28488d9468c0fad00cb7450b9" 15 | -------------------------------------------------------------------------------- /wit/deps.toml: -------------------------------------------------------------------------------- 1 | logging = "https://github.com/WebAssembly/wasi-logging/archive/main.tar.gz" 2 | clocks = "https://github.com/WebAssembly/wasi-clocks/archive/main.tar.gz" 3 | -------------------------------------------------------------------------------- /wit/deps/clocks/monotonic-clock.wit: -------------------------------------------------------------------------------- 1 | package wasi:clocks@0.2.1; 2 | /// WASI Monotonic Clock is a clock API intended to let users measure elapsed 3 | /// time. 4 | /// 5 | /// It is intended to be portable at least between Unix-family platforms and 6 | /// Windows. 7 | /// 8 | /// A monotonic clock is a clock which has an unspecified initial value, and 9 | /// successive reads of the clock will produce non-decreasing values. 10 | @since(version = 0.2.0) 11 | interface monotonic-clock { 12 | @since(version = 0.2.0) 13 | use wasi:io/poll@0.2.1.{pollable}; 14 | 15 | /// An instant in time, in nanoseconds. An instant is relative to an 16 | /// unspecified initial value, and can only be compared to instances from 17 | /// the same monotonic-clock. 18 | @since(version = 0.2.0) 19 | type instant = u64; 20 | 21 | /// A duration of time, in nanoseconds. 22 | @since(version = 0.2.0) 23 | type duration = u64; 24 | 25 | /// Read the current value of the clock. 26 | /// 27 | /// The clock is monotonic, therefore calling this function repeatedly will 28 | /// produce a sequence of non-decreasing values. 29 | @since(version = 0.2.0) 30 | now: func() -> instant; 31 | 32 | /// Query the resolution of the clock. Returns the duration of time 33 | /// corresponding to a clock tick. 34 | @since(version = 0.2.0) 35 | resolution: func() -> duration; 36 | 37 | /// Create a `pollable` which will resolve once the specified instant 38 | /// has occurred. 39 | @since(version = 0.2.0) 40 | subscribe-instant: func( 41 | when: instant, 42 | ) -> pollable; 43 | 44 | /// Create a `pollable` that will resolve after the specified duration has 45 | /// elapsed from the time this function is invoked. 46 | @since(version = 0.2.0) 47 | subscribe-duration: func( 48 | when: duration, 49 | ) -> pollable; 50 | } 51 | -------------------------------------------------------------------------------- /wit/deps/clocks/timezone.wit: -------------------------------------------------------------------------------- 1 | package wasi:clocks@0.2.1; 2 | 3 | @unstable(feature = clocks-timezone) 4 | interface timezone { 5 | @unstable(feature = clocks-timezone) 6 | use wall-clock.{datetime}; 7 | 8 | /// Return information needed to display the given `datetime`. This includes 9 | /// the UTC offset, the time zone name, and a flag indicating whether 10 | /// daylight saving time is active. 11 | /// 12 | /// If the timezone cannot be determined for the given `datetime`, return a 13 | /// `timezone-display` for `UTC` with a `utc-offset` of 0 and no daylight 14 | /// saving time. 15 | @unstable(feature = clocks-timezone) 16 | display: func(when: datetime) -> timezone-display; 17 | 18 | /// The same as `display`, but only return the UTC offset. 19 | @unstable(feature = clocks-timezone) 20 | utc-offset: func(when: datetime) -> s32; 21 | 22 | /// Information useful for displaying the timezone of a specific `datetime`. 23 | /// 24 | /// This information may vary within a single `timezone` to reflect daylight 25 | /// saving time adjustments. 26 | @unstable(feature = clocks-timezone) 27 | record timezone-display { 28 | /// The number of seconds difference between UTC time and the local 29 | /// time of the timezone. 30 | /// 31 | /// The returned value will always be less than 86400 which is the 32 | /// number of seconds in a day (24*60*60). 33 | /// 34 | /// In implementations that do not expose an actual time zone, this 35 | /// should return 0. 36 | utc-offset: s32, 37 | 38 | /// The abbreviated name of the timezone to display to a user. The name 39 | /// `UTC` indicates Coordinated Universal Time. Otherwise, this should 40 | /// reference local standards for the name of the time zone. 41 | /// 42 | /// In implementations that do not expose an actual time zone, this 43 | /// should be the string `UTC`. 44 | /// 45 | /// In time zones that do not have an applicable name, a formatted 46 | /// representation of the UTC offset may be returned, such as `-04:00`. 47 | name: string, 48 | 49 | /// Whether daylight saving time is active. 50 | /// 51 | /// In implementations that do not expose an actual time zone, this 52 | /// should return false. 53 | in-daylight-saving-time: bool, 54 | } 55 | } 56 | -------------------------------------------------------------------------------- /wit/deps/clocks/wall-clock.wit: -------------------------------------------------------------------------------- 1 | package wasi:clocks@0.2.1; 2 | /// WASI Wall Clock is a clock API intended to let users query the current 3 | /// time. The name "wall" makes an analogy to a "clock on the wall", which 4 | /// is not necessarily monotonic as it may be reset. 5 | /// 6 | /// It is intended to be portable at least between Unix-family platforms and 7 | /// Windows. 8 | /// 9 | /// A wall clock is a clock which measures the date and time according to 10 | /// some external reference. 11 | /// 12 | /// External references may be reset, so this clock is not necessarily 13 | /// monotonic, making it unsuitable for measuring elapsed time. 14 | /// 15 | /// It is intended for reporting the current date and time for humans. 16 | @since(version = 0.2.0) 17 | interface wall-clock { 18 | /// A time and date in seconds plus nanoseconds. 19 | @since(version = 0.2.0) 20 | record datetime { 21 | seconds: u64, 22 | nanoseconds: u32, 23 | } 24 | 25 | /// Read the current value of the clock. 26 | /// 27 | /// This clock is not monotonic, therefore calling this function repeatedly 28 | /// will not necessarily produce a sequence of non-decreasing values. 29 | /// 30 | /// The returned timestamps represent the number of seconds since 31 | /// 1970-01-01T00:00:00Z, also known as [POSIX's Seconds Since the Epoch], 32 | /// also known as [Unix Time]. 33 | /// 34 | /// The nanoseconds field of the output is always less than 1000000000. 35 | /// 36 | /// [POSIX's Seconds Since the Epoch]: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16 37 | /// [Unix Time]: https://en.wikipedia.org/wiki/Unix_time 38 | @since(version = 0.2.0) 39 | now: func() -> datetime; 40 | 41 | /// Query the resolution of the clock. 42 | /// 43 | /// The nanoseconds field of the output is always less than 1000000000. 44 | @since(version = 0.2.0) 45 | resolution: func() -> datetime; 46 | } 47 | -------------------------------------------------------------------------------- /wit/deps/clocks/world.wit: -------------------------------------------------------------------------------- 1 | package wasi:clocks@0.2.1; 2 | 3 | @since(version = 0.2.0) 4 | world imports { 5 | @since(version = 0.2.0) 6 | import monotonic-clock; 7 | @since(version = 0.2.0) 8 | import wall-clock; 9 | @unstable(feature = clocks-timezone) 10 | import timezone; 11 | } 12 | -------------------------------------------------------------------------------- /wit/deps/io/error.wit: -------------------------------------------------------------------------------- 1 | package wasi:io@0.2.1; 2 | 3 | @since(version = 0.2.0) 4 | interface error { 5 | /// A resource which represents some error information. 6 | /// 7 | /// The only method provided by this resource is `to-debug-string`, 8 | /// which provides some human-readable information about the error. 9 | /// 10 | /// In the `wasi:io` package, this resource is returned through the 11 | /// `wasi:io/streams/stream-error` type. 12 | /// 13 | /// To provide more specific error information, other interfaces may 14 | /// offer functions to "downcast" this error into more specific types. For example, 15 | /// errors returned from streams derived from filesystem types can be described using 16 | /// the filesystem's own error-code type. This is done using the function 17 | /// `wasi:filesystem/types/filesystem-error-code`, which takes a `borrow` 18 | /// parameter and returns an `option`. 19 | /// 20 | /// The set of functions which can "downcast" an `error` into a more 21 | /// concrete type is open. 22 | @since(version = 0.2.0) 23 | resource error { 24 | /// Returns a string that is suitable to assist humans in debugging 25 | /// this error. 26 | /// 27 | /// WARNING: The returned string should not be consumed mechanically! 28 | /// It may change across platforms, hosts, or other implementation 29 | /// details. Parsing this string is a major platform-compatibility 30 | /// hazard. 31 | @since(version = 0.2.0) 32 | to-debug-string: func() -> string; 33 | } 34 | } 35 | -------------------------------------------------------------------------------- /wit/deps/io/poll.wit: -------------------------------------------------------------------------------- 1 | package wasi:io@0.2.1; 2 | 3 | /// A poll API intended to let users wait for I/O events on multiple handles 4 | /// at once. 5 | @since(version = 0.2.0) 6 | interface poll { 7 | /// `pollable` represents a single I/O event which may be ready, or not. 8 | @since(version = 0.2.0) 9 | resource pollable { 10 | 11 | /// Return the readiness of a pollable. This function never blocks. 12 | /// 13 | /// Returns `true` when the pollable is ready, and `false` otherwise. 14 | @since(version = 0.2.0) 15 | ready: func() -> bool; 16 | 17 | /// `block` returns immediately if the pollable is ready, and otherwise 18 | /// blocks until ready. 19 | /// 20 | /// This function is equivalent to calling `poll.poll` on a list 21 | /// containing only this pollable. 22 | @since(version = 0.2.0) 23 | block: func(); 24 | } 25 | 26 | /// Poll for completion on a set of pollables. 27 | /// 28 | /// This function takes a list of pollables, which identify I/O sources of 29 | /// interest, and waits until one or more of the events is ready for I/O. 30 | /// 31 | /// The result `list` contains one or more indices of handles in the 32 | /// argument list that is ready for I/O. 33 | /// 34 | /// This function traps if either: 35 | /// - the list is empty, or: 36 | /// - the list contains more elements than can be indexed with a `u32` value. 37 | /// 38 | /// A timeout can be implemented by adding a pollable from the 39 | /// wasi-clocks API to the list. 40 | /// 41 | /// This function does not return a `result`; polling in itself does not 42 | /// do any I/O so it doesn't fail. If any of the I/O sources identified by 43 | /// the pollables has an error, it is indicated by marking the source as 44 | /// being ready for I/O. 45 | @since(version = 0.2.0) 46 | poll: func(in: list>) -> list; 47 | } 48 | -------------------------------------------------------------------------------- /wit/deps/io/streams.wit: -------------------------------------------------------------------------------- 1 | package wasi:io@0.2.1; 2 | 3 | /// WASI I/O is an I/O abstraction API which is currently focused on providing 4 | /// stream types. 5 | /// 6 | /// In the future, the component model is expected to add built-in stream types; 7 | /// when it does, they are expected to subsume this API. 8 | @since(version = 0.2.0) 9 | interface streams { 10 | @since(version = 0.2.0) 11 | use error.{error}; 12 | @since(version = 0.2.0) 13 | use poll.{pollable}; 14 | 15 | /// An error for input-stream and output-stream operations. 16 | @since(version = 0.2.0) 17 | variant stream-error { 18 | /// The last operation (a write or flush) failed before completion. 19 | /// 20 | /// More information is available in the `error` payload. 21 | last-operation-failed(error), 22 | /// The stream is closed: no more input will be accepted by the 23 | /// stream. A closed output-stream will return this error on all 24 | /// future operations. 25 | closed 26 | } 27 | 28 | /// An input bytestream. 29 | /// 30 | /// `input-stream`s are *non-blocking* to the extent practical on underlying 31 | /// platforms. I/O operations always return promptly; if fewer bytes are 32 | /// promptly available than requested, they return the number of bytes promptly 33 | /// available, which could even be zero. To wait for data to be available, 34 | /// use the `subscribe` function to obtain a `pollable` which can be polled 35 | /// for using `wasi:io/poll`. 36 | @since(version = 0.2.0) 37 | resource input-stream { 38 | /// Perform a non-blocking read from the stream. 39 | /// 40 | /// When the source of a `read` is binary data, the bytes from the source 41 | /// are returned verbatim. When the source of a `read` is known to the 42 | /// implementation to be text, bytes containing the UTF-8 encoding of the 43 | /// text are returned. 44 | /// 45 | /// This function returns a list of bytes containing the read data, 46 | /// when successful. The returned list will contain up to `len` bytes; 47 | /// it may return fewer than requested, but not more. The list is 48 | /// empty when no bytes are available for reading at this time. The 49 | /// pollable given by `subscribe` will be ready when more bytes are 50 | /// available. 51 | /// 52 | /// This function fails with a `stream-error` when the operation 53 | /// encounters an error, giving `last-operation-failed`, or when the 54 | /// stream is closed, giving `closed`. 55 | /// 56 | /// When the caller gives a `len` of 0, it represents a request to 57 | /// read 0 bytes. If the stream is still open, this call should 58 | /// succeed and return an empty list, or otherwise fail with `closed`. 59 | /// 60 | /// The `len` parameter is a `u64`, which could represent a list of u8 which 61 | /// is not possible to allocate in wasm32, or not desirable to allocate as 62 | /// as a return value by the callee. The callee may return a list of bytes 63 | /// less than `len` in size while more bytes are available for reading. 64 | @since(version = 0.2.0) 65 | read: func( 66 | /// The maximum number of bytes to read 67 | len: u64 68 | ) -> result, stream-error>; 69 | 70 | /// Read bytes from a stream, after blocking until at least one byte can 71 | /// be read. Except for blocking, behavior is identical to `read`. 72 | @since(version = 0.2.0) 73 | blocking-read: func( 74 | /// The maximum number of bytes to read 75 | len: u64 76 | ) -> result, stream-error>; 77 | 78 | /// Skip bytes from a stream. Returns number of bytes skipped. 79 | /// 80 | /// Behaves identical to `read`, except instead of returning a list 81 | /// of bytes, returns the number of bytes consumed from the stream. 82 | @since(version = 0.2.0) 83 | skip: func( 84 | /// The maximum number of bytes to skip. 85 | len: u64, 86 | ) -> result; 87 | 88 | /// Skip bytes from a stream, after blocking until at least one byte 89 | /// can be skipped. Except for blocking behavior, identical to `skip`. 90 | @since(version = 0.2.0) 91 | blocking-skip: func( 92 | /// The maximum number of bytes to skip. 93 | len: u64, 94 | ) -> result; 95 | 96 | /// Create a `pollable` which will resolve once either the specified stream 97 | /// has bytes available to read or the other end of the stream has been 98 | /// closed. 99 | /// The created `pollable` is a child resource of the `input-stream`. 100 | /// Implementations may trap if the `input-stream` is dropped before 101 | /// all derived `pollable`s created with this function are dropped. 102 | @since(version = 0.2.0) 103 | subscribe: func() -> pollable; 104 | } 105 | 106 | 107 | /// An output bytestream. 108 | /// 109 | /// `output-stream`s are *non-blocking* to the extent practical on 110 | /// underlying platforms. Except where specified otherwise, I/O operations also 111 | /// always return promptly, after the number of bytes that can be written 112 | /// promptly, which could even be zero. To wait for the stream to be ready to 113 | /// accept data, the `subscribe` function to obtain a `pollable` which can be 114 | /// polled for using `wasi:io/poll`. 115 | /// 116 | /// Dropping an `output-stream` while there's still an active write in 117 | /// progress may result in the data being lost. Before dropping the stream, 118 | /// be sure to fully flush your writes. 119 | @since(version = 0.2.0) 120 | resource output-stream { 121 | /// Check readiness for writing. This function never blocks. 122 | /// 123 | /// Returns the number of bytes permitted for the next call to `write`, 124 | /// or an error. Calling `write` with more bytes than this function has 125 | /// permitted will trap. 126 | /// 127 | /// When this function returns 0 bytes, the `subscribe` pollable will 128 | /// become ready when this function will report at least 1 byte, or an 129 | /// error. 130 | @since(version = 0.2.0) 131 | check-write: func() -> result; 132 | 133 | /// Perform a write. This function never blocks. 134 | /// 135 | /// When the destination of a `write` is binary data, the bytes from 136 | /// `contents` are written verbatim. When the destination of a `write` is 137 | /// known to the implementation to be text, the bytes of `contents` are 138 | /// transcoded from UTF-8 into the encoding of the destination and then 139 | /// written. 140 | /// 141 | /// Precondition: check-write gave permit of Ok(n) and contents has a 142 | /// length of less than or equal to n. Otherwise, this function will trap. 143 | /// 144 | /// returns Err(closed) without writing if the stream has closed since 145 | /// the last call to check-write provided a permit. 146 | @since(version = 0.2.0) 147 | write: func( 148 | contents: list 149 | ) -> result<_, stream-error>; 150 | 151 | /// Perform a write of up to 4096 bytes, and then flush the stream. Block 152 | /// until all of these operations are complete, or an error occurs. 153 | /// 154 | /// This is a convenience wrapper around the use of `check-write`, 155 | /// `subscribe`, `write`, and `flush`, and is implemented with the 156 | /// following pseudo-code: 157 | /// 158 | /// ```text 159 | /// let pollable = this.subscribe(); 160 | /// while !contents.is_empty() { 161 | /// // Wait for the stream to become writable 162 | /// pollable.block(); 163 | /// let Ok(n) = this.check-write(); // eliding error handling 164 | /// let len = min(n, contents.len()); 165 | /// let (chunk, rest) = contents.split_at(len); 166 | /// this.write(chunk ); // eliding error handling 167 | /// contents = rest; 168 | /// } 169 | /// this.flush(); 170 | /// // Wait for completion of `flush` 171 | /// pollable.block(); 172 | /// // Check for any errors that arose during `flush` 173 | /// let _ = this.check-write(); // eliding error handling 174 | /// ``` 175 | @since(version = 0.2.0) 176 | blocking-write-and-flush: func( 177 | contents: list 178 | ) -> result<_, stream-error>; 179 | 180 | /// Request to flush buffered output. This function never blocks. 181 | /// 182 | /// This tells the output-stream that the caller intends any buffered 183 | /// output to be flushed. the output which is expected to be flushed 184 | /// is all that has been passed to `write` prior to this call. 185 | /// 186 | /// Upon calling this function, the `output-stream` will not accept any 187 | /// writes (`check-write` will return `ok(0)`) until the flush has 188 | /// completed. The `subscribe` pollable will become ready when the 189 | /// flush has completed and the stream can accept more writes. 190 | @since(version = 0.2.0) 191 | flush: func() -> result<_, stream-error>; 192 | 193 | /// Request to flush buffered output, and block until flush completes 194 | /// and stream is ready for writing again. 195 | @since(version = 0.2.0) 196 | blocking-flush: func() -> result<_, stream-error>; 197 | 198 | /// Create a `pollable` which will resolve once the output-stream 199 | /// is ready for more writing, or an error has occurred. When this 200 | /// pollable is ready, `check-write` will return `ok(n)` with n>0, or an 201 | /// error. 202 | /// 203 | /// If the stream is closed, this pollable is always ready immediately. 204 | /// 205 | /// The created `pollable` is a child resource of the `output-stream`. 206 | /// Implementations may trap if the `output-stream` is dropped before 207 | /// all derived `pollable`s created with this function are dropped. 208 | subscribe: func() -> pollable; 209 | 210 | /// Write zeroes to a stream. 211 | /// 212 | /// This should be used precisely like `write` with the exact same 213 | /// preconditions (must use check-write first), but instead of 214 | /// passing a list of bytes, you simply pass the number of zero-bytes 215 | /// that should be written. 216 | @since(version = 0.2.0) 217 | write-zeroes: func( 218 | /// The number of zero-bytes to write 219 | len: u64 220 | ) -> result<_, stream-error>; 221 | 222 | /// Perform a write of up to 4096 zeroes, and then flush the stream. 223 | /// Block until all of these operations are complete, or an error 224 | /// occurs. 225 | /// 226 | /// This is a convenience wrapper around the use of `check-write`, 227 | /// `subscribe`, `write-zeroes`, and `flush`, and is implemented with 228 | /// the following pseudo-code: 229 | /// 230 | /// ```text 231 | /// let pollable = this.subscribe(); 232 | /// while num_zeroes != 0 { 233 | /// // Wait for the stream to become writable 234 | /// pollable.block(); 235 | /// let Ok(n) = this.check-write(); // eliding error handling 236 | /// let len = min(n, num_zeroes); 237 | /// this.write-zeroes(len); // eliding error handling 238 | /// num_zeroes -= len; 239 | /// } 240 | /// this.flush(); 241 | /// // Wait for completion of `flush` 242 | /// pollable.block(); 243 | /// // Check for any errors that arose during `flush` 244 | /// let _ = this.check-write(); // eliding error handling 245 | /// ``` 246 | @since(version = 0.2.0) 247 | blocking-write-zeroes-and-flush: func( 248 | /// The number of zero-bytes to write 249 | len: u64 250 | ) -> result<_, stream-error>; 251 | 252 | /// Read from one stream and write to another. 253 | /// 254 | /// The behavior of splice is equivalent to: 255 | /// 1. calling `check-write` on the `output-stream` 256 | /// 2. calling `read` on the `input-stream` with the smaller of the 257 | /// `check-write` permitted length and the `len` provided to `splice` 258 | /// 3. calling `write` on the `output-stream` with that read data. 259 | /// 260 | /// Any error reported by the call to `check-write`, `read`, or 261 | /// `write` ends the splice and reports that error. 262 | /// 263 | /// This function returns the number of bytes transferred; it may be less 264 | /// than `len`. 265 | @since(version = 0.2.0) 266 | splice: func( 267 | /// The stream to read from 268 | src: borrow, 269 | /// The number of bytes to splice 270 | len: u64, 271 | ) -> result; 272 | 273 | /// Read from one stream and write to another, with blocking. 274 | /// 275 | /// This is similar to `splice`, except that it blocks until the 276 | /// `output-stream` is ready for writing, and the `input-stream` 277 | /// is ready for reading, before performing the `splice`. 278 | @since(version = 0.2.0) 279 | blocking-splice: func( 280 | /// The stream to read from 281 | src: borrow, 282 | /// The number of bytes to splice 283 | len: u64, 284 | ) -> result; 285 | } 286 | } 287 | -------------------------------------------------------------------------------- /wit/deps/io/world.wit: -------------------------------------------------------------------------------- 1 | package wasi:io@0.2.1; 2 | 3 | @since(version = 0.2.0) 4 | world imports { 5 | @since(version = 0.2.0) 6 | import streams; 7 | 8 | @since(version = 0.2.0) 9 | import poll; 10 | } 11 | -------------------------------------------------------------------------------- /wit/deps/logging/logging.wit: -------------------------------------------------------------------------------- 1 | /// WASI Logging is a logging API intended to let users emit log messages with 2 | /// simple priority levels and context values. 3 | interface logging { 4 | /// A log level, describing a kind of message. 5 | enum level { 6 | /// Describes messages about the values of variables and the flow of 7 | /// control within a program. 8 | trace, 9 | 10 | /// Describes messages likely to be of interest to someone debugging a 11 | /// program. 12 | debug, 13 | 14 | /// Describes messages likely to be of interest to someone monitoring a 15 | /// program. 16 | info, 17 | 18 | /// Describes messages indicating hazardous situations. 19 | warn, 20 | 21 | /// Describes messages indicating serious errors. 22 | error, 23 | 24 | /// Describes messages indicating fatal errors. 25 | critical, 26 | } 27 | 28 | /// Emit a log message. 29 | /// 30 | /// A log message has a `level` describing what kind of message is being 31 | /// sent, a context, which is an uninterpreted string meant to help 32 | /// consumers group similar messages, and a string containing the message 33 | /// text. 34 | log: func(level: level, context: string, message: string); 35 | } 36 | -------------------------------------------------------------------------------- /wit/deps/logging/world.wit: -------------------------------------------------------------------------------- 1 | package wasi:logging; 2 | 3 | world imports { 4 | import logging; 5 | } 6 | -------------------------------------------------------------------------------- /wit/tracer.wit: -------------------------------------------------------------------------------- 1 | interface tracer { 2 | use wasi:clocks/wall-clock@0.2.1.{datetime}; 3 | 4 | /// Starts a new `span` with the given name and options. 5 | start: func(name: string, options: option) -> span; 6 | 7 | /// Represents a unit of work or operation. 8 | resource span { 9 | /// Get the `span-context` for this `span`. 10 | span-context: func() -> span-context; 11 | 12 | /// Returns true when the data provided to this `span` is captured in some form. If it returns false then any data provided is discarded. 13 | is-recording: func() -> bool; 14 | 15 | /// Set attributes of this span. 16 | /// 17 | /// If a key already exists for an attribute of the Span it will be overwritten with the corresponding new value. 18 | set-attributes: func(attributes: list); 19 | 20 | /// Adds an event with the provided name at the curent timestamp. 21 | /// 22 | /// Optionally an alternative timestamp may be provided. You may also provide attributes of this event. 23 | add-event: func(name: string, timestamp: option, attributes: option>); 24 | 25 | /// Associates this `span` with another. 26 | add-link: func(link: link); 27 | 28 | /// Override the default `span` status, which is unset. 29 | set-status: func(status: status); 30 | 31 | /// Updates the `span` name. 32 | update-name: func(name: string); 33 | 34 | /// Signals that the operation described by this span has now ended. 35 | /// 36 | /// If a timestamp is not provided then it is treated equivalent to passing the current time. Dropping this resource is the equivalent of calling `end(none)`. 37 | end: func(timestamp: option); 38 | } 39 | 40 | /// Configuration for starting a `span`. 41 | record start-options { 42 | /// Whether this span should act as the root of a new trace. 43 | new-root: bool, 44 | /// `span-kind` for the new `span`. 45 | span-kind: option, 46 | /// Attributes for the new `span`. 47 | attributes: option>, 48 | /// `link`'s for the new `span`. 49 | links: option>, 50 | /// When the `span` should begin. If this is not provided it defaults to the current time. 51 | timestamp: option, 52 | } 53 | 54 | /// Describes a relationship to another `span`. 55 | record link { 56 | /// Denotes which `span` to link to. 57 | span-context: span-context, 58 | /// Attributes describing the link. 59 | attributes: list, 60 | } 61 | 62 | /// Describes the relationship between the Span, its parents, and its children in a trace. 63 | enum span-kind { 64 | /// Indicates that the span describes a request to some remote service. This span is usually the parent of a remote server span and does not end until the response is received. 65 | client, 66 | /// Indicates that the span covers server-side handling of a synchronous RPC or other remote request. This span is often the child of a remote client span that was expected to wait for a response. 67 | server, 68 | /// Indicates that the span describes the initiators of an asynchronous request. This parent span will often end before the corresponding child consumer span, possibly even before the child span starts. In messaging scenarios with batching, tracing individual messages requires a new producer span per message to be created. 69 | producer, 70 | /// Indicates that the span describes a child of an asynchronous consumer request. 71 | consumer, 72 | /// Default value. Indicates that the span represents an internal operation within an application, as opposed to an operations with remote parents or children. 73 | internal 74 | } 75 | 76 | /// The `status` of a `span`. 77 | variant status { 78 | /// The default status. 79 | unset, 80 | /// The operation has been validated by an Application developer or Operator to have completed successfully. 81 | ok, 82 | /// The operation contains an error with a description. 83 | error(string), 84 | } 85 | 86 | /// A key-value pair describing an attribute. 87 | record key-value { 88 | /// The attribute name. 89 | key: key, 90 | /// The attribute value. 91 | value: value, 92 | } 93 | 94 | /// The key part of attribute `key-value` pairs. 95 | type key = string; 96 | 97 | /// The value part of attribute `key-value` pairs. 98 | variant value { 99 | /// A string value. 100 | %string(string), 101 | /// A boolean value. 102 | %bool(bool), 103 | /// A double precision floating point value. 104 | %float64(float64), 105 | /// A signed 64 bit integer value. 106 | %s64(s64), 107 | /// A homogeneous array of string values. 108 | string-array(list), 109 | /// A homogeneous array of boolean values. 110 | bool-array(list), 111 | /// A homogeneous array of double precision floating point values. 112 | float64-array(list), 113 | /// A homogeneous array of 64 bit integer values. 114 | s64-array(list), 115 | } 116 | 117 | /// Identifying trace information about a span that can be serialized and propagated. 118 | record span-context { 119 | /// The `trace-id` for this `span-context`. 120 | trace-id: trace-id, 121 | /// The `span-id` for this `span-context`. 122 | span-id: span-id, 123 | /// The `trace-flags` for this `span-context`. 124 | trace-flags: trace-flags, 125 | /// Whether this `span-context` was propagated from a remote parent. 126 | is-remote: bool, 127 | /// The `trace-state` for this `span-context`. 128 | trace-state: trace-state, 129 | } 130 | 131 | /// The trace that this `span-context` belongs to. 132 | /// 133 | /// 16 bytes encoded as a hexadecimal string. 134 | type trace-id = string; 135 | 136 | /// The id of this `span-context`. 137 | /// 138 | /// 8 bytes encoded as a hexadecimal string. 139 | type span-id = string; 140 | 141 | /// Flags that can be set on a `span-context`. 142 | flags trace-flags { 143 | /// Whether the `span` should be sampled or not. 144 | sampled, 145 | } 146 | 147 | /// Carries system-specific configuration data, represented as a list of key-value pairs. `trace-state` allows multiple tracing systems to participate in the same trace. 148 | /// 149 | /// If any invalid keys or values are provided then the `trace-state` will be treated as an empty list. 150 | type trace-state = list>; 151 | } 152 | -------------------------------------------------------------------------------- /wit/world.wit: -------------------------------------------------------------------------------- 1 | package wasi:observe; 2 | 3 | world imports { 4 | import wasi:logging/logging; 5 | import tracer; 6 | } 7 | --------------------------------------------------------------------------------