Should we try to establish this as the de facto successor fork of ESPAsyncWebServer?

[egnor]

Right now the situation is a giant mess with hundreds of forks, several active ones, and the Arduino and platformio registries pointing at different and (in the case of Arduino) obscure forks.

This library is widely used but the source appears to be abandoned, no longer works with current platform versions and is also very, very, very buggy, so it sure would be nice to consolidate development...

[mathieucarbou]

Right now the situation is a giant mess with hundreds of forks, several active ones, and the Arduino and platformio registries pointing at different and (in the case of Arduino) obscure forks.

I agree.

This library is widely used but the source appears to be abandoned, no longer works with current platform versions and is also very, very, very buggy

If you are talking about the original repo from me-no-dev, yes I agree.

so it sure would be nice to consolidate development...

That was my idea behind this fork.
All the pieces, fixes, were available, it just needed a little love to consolidate, refresh with new ArduinoJson versions, ESP-IDF 5.x, etc
And, especially, someone available to keep it alive and merge incoming PRs.

The more people will use this fork, the more it will establish itself as a good alternative.

Also, don't forget that there is also PsychicHttp, backed by the ESP-IDF API.
This can be a good alternative for some projects, but PsychicHttp also has its own issues from what I've seen:

• No 8266 support
• No RP2040 support
• No AsyncCallbackJsonWebHandler equivalent
• No HTTP_ANY equivalent
• No rewrite
• Not API compatible
• Too few people are using PsychicHttp, so making a project or library compatible with it often requires to use defines to switch between PsychicHttp and ESPAsyncWebServer
• Uses too much memory: spawns 8 workers of 4k stack for each so 32k stack reserved and not fully used
• There is pretty much no activity anymore
• The project is still in development, they are still breaking APIs a lot, renaming files (even second digit increment in versions - so they do not respect the semver convention) - https://github.com/hoeken/PsychicHttp/releases

I personally really think that PsychicHttp had a very good idea in using the existing ESP-IDF API behind, but sadly the way it was implemented does not help its adoption. But I am convinced that an implementation of ESPAsyncWebServer backed by the ESP-IDF API would be very welcomed, and would help getting rid of the Async TCP library also.

[egnor]

(Sorry, didn't realize you had discussions on or I would have put it here in the first place!)

And sorry yes the "very, very, very buggy" was about the original me-no-dev repo. Forks vary widely in how many fixes have been applied, which is part of the problem, and IMHO why we need a canonical place with all the fixes -- and this repo seems like a good start. (The esphome repo would be the other main candidate but I assume its maintainers are more interested in their main esphome project?)

Also despite claims and anecdotes to the contrary I actually think PsychicHttp has its own threading issues, because the ESP-IDF API still makes calls on the system event loop which is its own thread. I posted this inquiry but haven't heard back yet (it's only been a couple days though).

For my own project I switched to the Mongoose library. It seems to be super solid, does work out of the box on ESP32, uses nonblocking IO instead of threads, and includes HTTP, MQTT, WS, etc. -- I think it's seriously underrated. There's a project to make an Arduino-style wrapper for it which has been dormant for a while but the dev says they're working on it. HOWEVER Mongoose by default uses BSD sockets which the ESP net layer supports but you couldn't just drop in something like the Arduino W5500 library. You can swap out Mongoose's network layer but it depends on nonblocking sockets of some kind. (Of course ESPAsyncWebServer depends on threadsafe network layer which also isn't a given... edit: see below)

[egnor]

Actually now that I think about it ESPAsyncWebServer depends on AsyncTCP which uses the lwip APIs specifically, so like Mongoose it won't work on top of an Arduino Client type network provider but needs an lwip implementation of some kind. So that's pretty equivalent.

[mathieucarbou]

Oh yes I forgot about Mongoose. I've seen several projects with it. When a project does not depend on a lot of web related dependencies, that's the best option I think. I know the project from Jeremy also. I think Jeremy is now working pretty much full time on OpenEVSE (which I have also contributed too - I have built an EVSE box for my EV car), and OpenEVSE is using this wrapper also.

There is no better or worse: this is the project needs that will dictate which one to use. For example I am using MycilaESPConnect, WebSerial, ESP-DASH, etc in some apps. These are all libraries that have 8266 / RP2040 support and rely on this fork. So consequently, these apps will never use Mongoose or Psychic.

[egnor]

Hypothetically one could implement an ESPAsyncWebServer compatible interface on top of one of the others, but I'm certainly not volunteering to do that!

[mathieucarbou]

Ahah! I think the same ;-)

[egnor]

OK so what needs to happen to establish this as the main ESPAsyncWebServer fork? Reach out to the maintainers of the other major forks (esphome and yubox-node-org) and see what they think?

[mathieucarbou]

I don't know. You opened the discussion, so I thought you had some plans and wanted to do something about it ;-)

But frankly, I'm not sure anything can be done. Anyone can fork and create its own version. There's nothing to prevent that. The only action that could be done is to provide more visibility to this fork to naturally redirect people, for example in answering issues on these projects, or even by opening a new issue in these projects with a title like PLEASE REDIRECT YOU ISSUES HERE....

I think the key is especially at mid-term to get some contributors in this fork with write access who can also help review and merge Prs, so that the project does not depend just on me. I am used to create long-lasting oss projects, and in one of them I created more than 15 years ago, which is used at many places, companies and foundations like Apache, there are now some contributors with write access and most of the project is maintained by the folks from Apache who are paid to do that. I just issue releases from time to time.

Any one-man show will be dead at one point. A project needs a team of people to live and last long.

[egnor]

Haha do I look like someone with a plan?? 😄

Well if you're at least willing to be the maintainer and do the work of being a collection point for fixes and improvements that's something! (Some of the rest of us can help a little bit hopefully...)

I'll check with the people who run the other forks and see what they think.

[mathieucarbou]

That was my plan also to - hopefully - get some help ;-)

[egnor]

OK, updated esphome#34 to more specifically float the question.

[vortigont]

I have a suggestion to start with. You need to detach your from fork from the original repo. I.e., now it has a link forked from yubox-node-org/ESPAsyncWebServer which is also a fork. So GitHub considers it as a fork indeed not an individual project.
It relates to contribution counters, indexing, etc...
You can detach it from upstream completely (do not worry, all contribution history will remain) and then promote it as a separate project which is a fork of blah-blah... I've done same for some of the abandoned projects which I continue developing on my own. To do this, you need to open a ticket via chat bot here, mention the reason that your fork has diverged significantly. It will take about several hours to complete the request.
Another step to consider is to rename the repo so that it won't conflict with the origin during lib dependency resolution and Platformio/Arduino's registry.
That will be a good kickstart to show that this is not just github fork with some patches applied, but a separate project that is developed and supported on it's own way.

[mathieucarbou]

you can detach it from upstream completely

I thought about that and there are sone drawbacks too. I want this project to stay as a "fork" by fork I mean a maintained derivate.

The reason is that:

• there is no new features (except some little things)
• only maintainance
• only bug fixes
• no API breakage
• People can see how much the repo has diverged easily by making diff with the original ones, which is not possible otehrwise from Github
• The history is also kept with original repos and Prs, IDE extensions are also able to see this project as derivate from other ones
• It gives better credit for the original authors
• Besides the git history, we also have the project derivation history, which is also a good thing to keep in order to follow the history of un-merged PRs, opened issues , etc which could still apply to this fork.

This is not a new project per see, but as I see it, a more active fork where a team of people would help keeping it alive, merging fixes and PRs.

The only significant change I did is the removal of the SPIDF Editor:

• to reduce the size of the lib
• to reduce the scope of maintenance
• to ficus this fork on what it should do: web server, and not a file manager
• SPIDF is anyway deprecated (but I know the implementation was compatible with any FS)
• If someone wants it, he can grab the 3 files needed from the yubox-node-org repo.

Another step to consider is to rename the repo so that it won't conflict with the origin during lib dependency resolution and Platformio/Arduino's registry.

There is no conflict: pio uses the github userid to prefix a project reference.
And for Arduino Lib, I am still deploying on top of the same library / same author.

We are just maintainers.

[egnor]

Not sure what you mean about the Arduino registry?

[mathieucarbou]

https://github.com/arduino/library-registry

[egnor]

Sorry, yes, I'm familiar with the registry, not sure what you meant by "still deploying on top of the same library / same author"

[vortigont]

@mathieucarbou If you detach your fork it will still maintain all history, PRs, etc.
As for me, this project diverged so significantly from me-nodev's origin that making any diffs and comparison wont' be of any use at all.
Yubox's changes were drastic long time ago.
Introducing new features - why not? API compatibility is nice, but why not expanding it further.
My understanding that original project is abandoned for good. Me-nodev now works for espressif as I understood, and IDF has it's own server implementation. Any further work will be a complete new implementation if ever.

Just my IMHO.

[mathieucarbou]

If you detach your fork it will still maintain all history, PRs, etc.

I know. am not talking about the git history. I am talking about the project history and the tools the IDE have to discover PRs and remotes from fork.

If at one point I see the need I will detach but for now it's not harmful. It also helps discovering this fork, and it is also published under the same name and even same author in Arduino repo.

To make a //, if me-no-dev added some people as contributors (or me), I wouldn't have created this repo but I would have stated in me-no-dev repo. That is not a new project per see. This fork is a shell allowing for maintenance and deployment in different library managers.

Introducing new features

Like said, that's not my goal for this fork. I don't have the time nor the money and I am not paid for that either, neither I receive sponsoring or donations for that. The only effort I am willing to provide regarding ESPAsyncWebServer is helping to keep it alive, maintained, and API-compatible.

But if someone wants to open a PR for a new feature that is in the spirit of the original library, that's totally fine.

If someone wants to rewrite the entire implementation but still keep it API-compatible, that's totally fine also.

I just didn't create this fork to take over the development from me-no-dev and in the idea of completely rework it.

[vortigont]

Reasonable. OK, we'll see if more ppl would be willing to contribute to this fork, I think there are plenty of thing to improve.
Will try to add something from my side also, not just do bla-bla talks :)