Closed dognotdog closed 2 years ago
Thank you for this PR! I think this is a good way of implementing this and we should push it forward.
I just have a couple comments, and I'm thinking that you already know them and were just waiting for feedback on the general approach. Here they are anyway:
VintageNetWiFi.Event
struct with the fields? I have half-baked ideas for additional fields, but I don't want figuring them out to slow this PR down. Making them structs should allow for future expansion.
- Instead of posting tuples. Could you make a
VintageNetWiFi.Event
struct with the fields? I have half-baked ideas for additional fields, but I don't want figuring them out to slow this PR down. Making them structs should allow for future expansion.
How should the non-applicable fields be treated? The two events described seem to have completely disjoint fields. Maybe creating unique types for each would work, in which case the "event name" would not have to passed on at all, and they could be matched on type?
I'm not sure how many event types there will end up being. How about just using a map that has one required field, :name
and then has optional fields depending on whatever makes sense for now.
@fhunleth added the respective updates to use an actual Event
struct and some basic unit tests.
Next time you send a PR, could you get CI to pass? It looks like this time it's just a few extra newlines that could be removed with
mix format
, but it's nice knowing that Dialyzer passes too.
Yea I didn't understand what was going on, doing mix format
on my end didn't seem to do anything, but that might be due to some user config somewhere in the weeds... I'll dig into that some more
Merged in #129. Thank you for getting this feature started and sorry for the long wait.
This implements the suggestion in #86 naively, maybe there are ways to improve on this? I've tested it as far as that it does correctly emits
CTRL-EVENT-ASSOC-REJECT
, whileCTRL-EVENT-SSID-TEMP-DISABLED
seems a bit more elusive.