Build Failure on rustc 1.45.2 stable channel about lighthouse HOT 5 CLOSED

Here's a quick prototype I threw together, notably it requires making the API async: https://gist.github.com/ssnover95/5877fef6b81dc5d8c16ab7518488aa00

Console Output:

SearchResponse { location: "http://192.168.1.7:80/description.xml", st: RootDevice, usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f::upnp:rootdevice", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }
SearchResponse { location: "http://192.168.1.7:80/description.xml", st: UUID("2f402f80-da50-11e1-9b23-ecb5fa0ea38f"), usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }
SearchResponse { location: "http://192.168.1.7:80/description.xml", st: URN(Device("schemas-upnp-org", "basic", 1)), usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }
SearchResponse { location: "http://192.168.1.7:80/description.xml", st: RootDevice, usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f::upnp:rootdevice", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }
SearchResponse { location: "http://192.168.1.7:80/description.xml", st: UUID("2f402f80-da50-11e1-9b23-ecb5fa0ea38f"), usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }
SearchResponse { location: "http://192.168.1.7:80/description.xml", st: URN(Device("schemas-upnp-org", "basic", 1)), usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }

from lighthouse.

Upon doing some further research, it looks like the ssdp package uses an unstable feature on Ipv6Addr, is_global(). This was very close to being stabilized earlier this year, but there were some concerns with some of the other APIs being stabilized along with it. Here's the tracking issue: rust-lang/rust#27709 And the PR stabilizing the API: rust-lang/rust#66584

I suspect it's not really worth subbing out the dependency for discovery over it, especially if it could be fixed in an upstream crate at some point in the near future.

from lighthouse.

I think SSDP has caused me quite a lot of grief. I'd imagine a good way to letting it build is to use a feature gate and have SSDP based discovery features be opt-out for end users wanting to build on stable?

If there's other more convenient and well maintained projects out there doing the job, I would be happy to switch.

from lighthouse.

Unfortunately, ssdp-client doesn't nicely expose the IpAddr like ssdp does. You can see the representation of the SearchResponse that I debug printed to my terminal output includes location. Perhaps they'd be willing to add an API which parses the SocketAddr from that field and returns it.

from lighthouse.

You could parse the location as a path or a URI, I can't remember which one would be more convenient. This struct here https://docs.rs/http/0.2.1/http/uri/struct.Uri.html for example implements a TryFrom trait which allows you to parse strings into a URI and then we can extract the IP or we could use https://docs.rs/url/2.1.1/url/struct.Url.html. Given this is done in a very limited set of scenarios / times it won't impact our performance or much of anything except adds an extra dependency.

from lighthouse.