Use control schema for messages #49
Conversation
If more parameters are introduced, the "if let" approach would involve ever increasing levels of indentation. With dedicated matcher statements, new parameters can be added without indentations.
The smaller functions make the code more readable and enable a more functional syntax.
Since the new method will just return a Gateway with the exact same parameters, we can also use the constructor directly, like in the synchronous module.
The SearchState will be re-introduced with states related to the search itself. The current "SearchState" is representing the state of the Requests, hence the renaming.
The new way of controlling the search process allows to expand it with additional stages.
According to the specification for [UPnP Devices][1], the arguments for the control actions need to match the order of arguments as desribed in the schema. To achieve that, we retrieve the schemas when searching for a compitable gateway and use the appropriate schema for each action to build the arguments properly. [1]: https://openconnectivity.org/upnp-specs/UPnP-arch-DeviceArchitecture-v2.0-20200417.pdf
This way we can use the logging macros in the whole library, not only in aio.
To panic is not a nice way of handling unintended behavior of a library. In case the router presents us with arguments we do not know about, issue a warning via the logger, but do not bail out. Proceed as if everything is okay and let the router decide whether it was fatal.
The concrete implementation of Future resulted in hard to read code, with loops and pattern matching and passing status objects around. Since we do not introduce new polling mechanisms here, but instead rely on the implementations of hyper and tokio, it is sufficient to work with async/.await instead of providing our own implementation of Future. The resulting code is much shorter and easier to understand.
|
Hi Simon, I rewrote the aio.search module, this time without the Future implementation and just with |
|
Looks good, I just have a few comments about the unwraps. |
|
I rewrote the unchecked |
|
Looks! I'm gonna go a bit more testing and then merge. Are you ok with a squash merge? |
Personally, I don't like squash merges. It creates one huge commit, that is difficult to read and understand and it makes |
|
I usually have a workflow that works well with squashes. I felt like I should ask here because you put a lot of care into making clean commits, so I won't squash it. |
Thanks, it is exactly because of the reason I mentioned and it fits well in my workflow. You should choose a method that fits with your usual workflow, I am fine with either way. :-) |
|
Thanks, I've published 0.11.0 with this fix. |
|
Great to hear, thank you very much! |
According to the specification for UPnP Devices, the arguments for the control actions need to match the order of arguments as desribed in the schema. To achieve that, we retrieve the schemas when searching for a compitable gateway and use the appropriate schema for each action to build the arguments properly.
Fixes #48.