WiFiServer - don't inherit from Print and Server

[JAndrassy]

Arduino has a base class Server. It is inherited from the Print class. The official base class Server has only virtual void begin()=0;. The Server class can't declare other required server methods available() and accept(), because they have the return type of the specific Client implementation of the library (for example EthernetClient in the Ethernet library). In ESP32 core the Server class is even modified (so external networking libraries produce an error).. It is not possible to use the base class Server to work with an instance of an inherited class.

Class Server inherits from Print for the print-to-all-clients functionality. This functionality is tied with a proper available() method implementation. The implementation of the Server class should register all connected clients for correct implementation of available() and for print-to-all-clients functionality. The ESP32 WiFiServer doesn't manage clients for available() and print-to-all-clients. The write method is unimplemented.

This PR removes the inheritance from Server and Print. ESP8266 did it almost two years ago. For ESP8266 I wrote ArduinoWiFiServer which inherits from WiFiServer and Print and manages the clients for proper available() and print-to-all-clients. But I doubt somebody uses it. My NetApiHelpers library has ArduinoWiFiServer for ESP32, older version of esp8266 and MbedCore

[SuGlider]

@JAndrassy - I understand that this PR wants to make WiFiServer class to expose the same APIs as Arduino ESP8266 WiFiServer does.

But looking into Arduino.cc implementation for WiFiServer I see exactly the same as we do in ESP32 Arduino.
https://github.com/arduino-libraries/WiFi/blob/master/src/WiFiServer.h

I'm not sure why we should follow ESP8226 and not the UpStream Arduino implementation.

Could you please elaborate more about it?
Thanks!

I also found an Arduino.cc example that uses Print Class write():
https://github.com/arduino-libraries/WiFi/blob/master/examples/WiFiChatServer/WiFiChatServer.ino

Therefore, the changes proposed in this PR would not allow this example to work.
I'm open to hearing your arguments, so please don't just close this PR.

[SuGlider]

Please explain more about the change.

[JAndrassy]

this PR a cleanup suggestion. removing code which never worked. what is unclear in the description of the PR in the first comment?
the esp32 WiFiServer is a copy of the esp8266 WiFiServer. It doesn't work like WiFiServer in Arduino's WiFi libraries.
and users request the esp8266 way, not the Arduino way.

you can read more about the 'Arduino' server.available() and print-to-all-clents here. The esp8266 and esp32 WiFiServer don't implememt that.

[JAndrassy]

I was thinking about better explanation:
By inheriting from Server base class the WiFiServer class declares that it works as Arduino Server. But it doesn't. It doesn't manage clients for proper available() and print-to-all-clients (for which Server inherits from Print).
Changing the implementation of esp8266/esp32 WiFiServer would be a big breaking change without good reason. It would change how server.available() in 'esp' WiFiServer works.
So my recommendation is to remove inheritance from Server and the associated empty write function.

[VojtechBartoska]

Same here, we are not able to merge. We need to keep align with Arduino.cc and this introduce a breaking change, closing. Thanks for understanding.

[JAndrassy]

do you plan to implement the print-to-all-clents function? make the write work? the WiFiServer then has to manage the connected clients to print to all of them.

this example must work https://github.com/JAndrassy/Arduino/blob/d5eb265f78bff9deb7063d10030a02d021c8c66c/libraries/ESP8266WiFi/examples/PagerServer/PagerServer.ino#L61

in esp8266 core https://github.com/JAndrassy/Arduino/blob/master/libraries/ESP8266WiFi/src/ArduinoWiFiServer.h

[github-actions]

Warnings

⚠️

Some issues found for the commit messages in this PR: the commit message "WiFiServer - don't inherit from Print and Server": summary looks empty type/action looks empty Please fix these commit messages - here are some basic tips: follow Conventional Commits style correct format of commit message should be: <type/action>(<scope/component>): <summary>, for example fix(esp32): Fixed startup timeout issue allowed types are: change,ci,docs,feat,fix,refactor,remove,revert,test sufficiently descriptive message summary should be between 20 to 72 characters and start with upper case letter avoid Jira references in commit messages (unavailable/irrelevant for our customers) TIP: Install pre-commit hooks and run this check when committing (uses the Conventional Precommit Linter).

	Messages
📖	You might consider squashing your 4 commits (simplifying branch history).

👋 Hello JAndrassy, we appreciate your contribution to this project!

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Resolve all warnings (⚠️ ) before requesting a review from human reviewers - they will appreciate it.
- Addressing info messages (📖) is strongly recommended; they're less critical but valuable.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests.

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
4. If the change is approved and passes the tests it is merged into the default branch.

Generated by 🚫 dangerJS against e465b41