search

ewilken / hap-rs

Rust implementation of the Apple HomeKit Accessory Protocol (HAP)
Apache License 2.0
196 stars 33 forks source link

Split up, or feature-gate HAP types vs other concepts (servers, storage, transport) #77

Open JeanMertz opened 2 years ago

JeanMertz commented 2 years ago

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.

ewilken commented 2 years ago

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.