zeroconf is a cross-platform library that wraps underlying ZeroConf/mDNS implementations such as Bonjour or Avahi, providing an easy and idiomatic way to both register and browse services.
For a use case connecting to services automatically and disconnecting when no longer available, it would be great if we could get an event or callback when a service was removed as seen with AVAHI_BROWSER_REMOVE and perhaps failing to resolve service after a Bonjour TTL timeout. I think it means the service is still available if the mDNS record is identical?
While I did look at the Bonjour code, and added a Hash/PartialEq impl for TxtRecord for deriving it for ServiceDiscovery, and added an generic event callback, I didn't spend much time figuring out how to support a the user-provided event loop poll timeout along with needing something like a per-second timeout internally to check cached entries.
While just something like a service_removed callback would be added here, I'd assume it would align better with zeroconf-tokio if it was a service_event for {added, removed, ...} instead.
In the meantime I can probably just recreate a browser upon a relevant user event, or some timeout on my library's side.
For a use case connecting to services automatically and disconnecting when no longer available, it would be great if we could get an event or callback when a service was removed as seen with
AVAHI_BROWSER_REMOVE
and perhaps failing to resolve service after a Bonjour TTL timeout. I think it means the service is still available if the mDNS record is identical?While I did look at the Bonjour code, and added a
Hash
/PartialEq
impl forTxtRecord
for deriving it forServiceDiscovery
, and added an generic event callback, I didn't spend much time figuring out how to support a the user-provided event loop poll timeout along with needing something like a per-second timeout internally to check cached entries.While just something like a
service_removed
callback would be added here, I'd assume it would align better withzeroconf-tokio
if it was aservice_event
for{added, removed, ...}
instead.In the meantime I can probably just recreate a browser upon a relevant user event, or some timeout on my library's side.