You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on a Rust crate for Homebridge that compiles to WASM. I'm rolling my own HAP types (services and characteristics), but wanted to see if there were any existing Rust crates that expose the relevant types for me. This crate comes closest, but I can't use it because it doesn't compile to the wasm32-unknown-unknown target, as it requires features that need access to OS-level features such as networking and file system access, which in turn requires the wasm32-wasi target (and then for crates to actually support that target).
I've seen #40 being discussed, but this request is different, in that I have no interest in anything but the accessory/service/characteristic types and the supporting API around them.
One solution would be to split off those types into a separate crate hap-types, another could be to feature-gate the non-type functionality of this create behind a feature flag(s) (e.g. server and storage, enabled by default for backward compatibility).
Any thoughts on this?
My project can continue as-is for now, but I like the idea of sharing common types across crates that deal with the HAP specification.
The text was updated successfully, but these errors were encountered:
My gut feeling is that splitting out something like a hap-types crate could make a lot of sense and would be preferable to feature-gating. I'd be happy to accept changes like that.
I'm working on a Rust crate for Homebridge that compiles to WASM. I'm rolling my own HAP types (services and characteristics), but wanted to see if there were any existing Rust crates that expose the relevant types for me. This crate comes closest, but I can't use it because it doesn't compile to the
wasm32-unknown-unknown
target, as it requires features that need access to OS-level features such as networking and file system access, which in turn requires thewasm32-wasi
target (and then for crates to actually support that target).I've seen #40 being discussed, but this request is different, in that I have no interest in anything but the accessory/service/characteristic types and the supporting API around them.
One solution would be to split off those types into a separate crate
hap-types
, another could be to feature-gate the non-type functionality of this create behind a feature flag(s) (e.g.server
andstorage
, enabled by default for backward compatibility).Any thoughts on this?
My project can continue as-is for now, but I like the idea of sharing common types across crates that deal with the HAP specification.
The text was updated successfully, but these errors were encountered: