-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change QNEthernet's setDnsServerIP() to setDNSServerIP() #8
Comments
I don't understand. Ethernet libraries have |
Before I can answer that, let me ask you this question: Are you trying to follow Arduino's Ethernet API (here) or the WiFiNINI API (here)? There's a case where the Ethernet API uses MACAddress(), while the WiFiNINA API uses macAddress(). Your project uses "macAddress()" and not "MACAddress()" for the common spelling. I agree with this because it keeps the naming style consistent. i.e. "start with a small-case letter". I tried to keep my API consistent with this naming scheme as well. Look also at setMACAddress() vs. setDnsServerIP() in the Ethernet API. Those are inconsistent. In the same way that you've chosen consistency with "macAddress()" vs. "MACAddress()", I've also chosen to use "setDNSServerIP()" vs. "setDnsServerIP()". Now, to keep my own API internally consistent, I have "setDNSServerIP()" and "dnsServerIP()" for both the "single server address" and the "nth server address" cases. Your document agrees with this naming convention because you have "setDNS()" vs. "setDns()". But, my API uses an index and your API uses a list of one or two DNS servers. Because I can have more than two DNS servers, I follow this convention:
I don't want to use the In summary, the correct way in QNEthernet to get the "nth" DNS server IP is |
I'll add a few miscellaneous notes I was just thinking about:
|
all function names are from WiFi API or Ethernet API as they are. APIs evolving over a long time sometimes in separate libraries and the combined back are usually inconsistent in many ways. In the API usage overview tables I use WiFi API names in the column title (if the WiFi API has that function) just because there are more WiFi libraries and some Ethernet libraries have the 'WiFi version' of the function name too. It is your library so you can have any functions and function names you want, of course. I recommend the set of functions of the legacy Ethernet API. And maybe having the WiFi alternatives for users coming from WiFi libraries or if a function doesn't exist in Ethernet API like for example DNS address getter with index dnsIP(n) or the two IP DNS setter from WiFi API setDNS. There are more documents in the repo now, all still work in progress. I still continue the research in details, I wrote test sketches to compare compilation and working of the libraries and I have discussions like this with developers in different repositories. You could add WiFi support to your library too :-) |
I think my main point is that in the table, the most correct thing to put for my library is “setDNSServerIP” vs. “setDnsServerIP”, for now. (We can always adjust in the future, as needed. This is just my request.) I’ll do some thinking about supporting the others, I just don’t love how “setDNS” and “dnsIP” have asymmetrical names and also asymmetrical arguments types and behaviours. Thanks again for caring about standards and standardization. |
the only way to set/add a DNS server is IP address. but you can query more than IP about a DNS server. there isn't a symmetry |
I edited the "Network interface getters and setters" section |
Cool. I'm going to think about it some more. |
Closing for now. I’ll come back with another issue if I have more requests. |
https://github.com/JAndrassy/Arduino-Networking-API/blob/639d731a124b7f7cdd5c70a7d48fe6c3b60956aa/ArduinoNetAPILibs.md?plain=1#L112
The text was updated successfully, but these errors were encountered: