Chris Dickinson (Oct 16 2023 at 18:37): Chris Dickinson (Oct 16 2023 at 18:37):Hi folks! I'm adding component model support for dylibso's observe-sdk and am running into #76 – in particular, the observe SDK adds a set of functions to the host interface (span-{enter,exit,tags}, log, etc) and I'd like to wrap them in a crate.
I have two options – one of which is implemented in a PR here.
Provide an observe-api crate which links to the appropriate core-module-level functions. This effectively "puns" the canonical abi. This has some upsides and downsides. The main upside is that we can provide a higher-level abstraction over the generated WIT interface. Right now that looks like being able to gracefully map log::Level and other enums to our WIT enums (which happen to be off-by-one.) I can see three downsides: users can still access the unwrapped, generated bindings through use bindings::dylibso::observe_sdk::api, the crate is effectively punning the ABI – which might change, and users have to represent this as two dependencies (one crate-level on observe-api, and one at the component.target level on the observe.wit bindings)
Alternatively, we could hold off on making a crate for now & provide user access exclusively through the bindings:: api. This is workable, but pushes more work onto the observe api user – e.g., they have to cast log::Level to generated bindings::dylibso::observe_sdk::api::LogLevel` before calling, etc. We kind of lose a communication channel with folks using the API – in the sense that a crate would give us the usual affordances like release versioning, a CHANGELOG, etc.
Ideally, I'd like to go with the first approach, with a stretch goal of having the observe_api crate somehow _contribute_ WIT interface imports automatically to dependent worlds. I'm not quite sure what that would look like, though. Would y'all have any recommendations for approaching this problem? Are there other folks solving something similar?
Last updated: Nov 25 2024 at 19:03 UTC