Organize framework C++ files in folders

[mjkl-gh]

First of many thanks for creating this template! It works really great and i'm loving it thusfar.

I'm implementing some extra functionality as in a serialclientservice and a streamserver (for serving serial over tcp) and writing it as a part of the framework instead of as a user extension. However, the framework folder contains a lot of files and no folders. I would like to organize the files in folders, however that would break pulling in the future.

Is it an idea to organize the C++ framework into folders in the source repo? I could open a pull request if this is something you'd want

Also if a serial+stream server is something you'd like in the project in the future I could open a PR for that when it's finished

[rjwats]

Hi Maarten,

With regards to restructuring, the project has possibly reached the point where it may benefit from some more structure to the source code. Though like you say, where users have modified the framework code the merge would be painful for them (as would be re-visiting my own WIPs). Awkward one.

Warning - brain dump below

I'm happy to look at any feature PRs, and your feature sounds useful. I certainly think the ability to view the serial output remotely, including in the UI would be a nice feature to have for debugging and monitoring. Others have expressed an interest in taking this further with "remote terminals" too.

In fact, I've attempted to do this in the past with limited success and there's some work in various branches which never made it's way into master. This thread has details of some of my attempts:

#123

I know that @proddy's project has developed a unified remote terminal over telnet/serial successfully, see project:

https://github.com/proddy/EMS-ESP

And I also know of projects such as the following which aim to support capture and transmission of Serial over TCP and/or WebSockets:

https://github.com/ayushsharma82/WebSerial
https://github.com/jeelabs/esp-link
https://github.com/JoaoLopesF/RemoteDebug

The second example (ESP-LINK) probably does the closest thing to what I was hoping to achieve.

I never reached an ideal solution, especially on the esp8266 which has such limited RAM. Failures such as dropped messages and buffer overflows were all too common for me, especially over WebSockets which always seems to have a very low transmission rate with the ESPAsyncWebServer. It worked much better on esp32 where there's more RAM.

I'm admittedly a C++ developer of only intermediate skill, and someone with more experience may be able to have a better crack at it, or at very least make code which fails more gracefully. I know what I wanted out of this feature, and I wonder how that fits in with what you are attempting to do. For me the key points were:

• Abstraction for logging - so logging can be redirected as required (freeing the Serial for use as a terminal if required).
• Persistent rolling logging to the FS - so a limited amount (configurable) of logs may be viewed later
• Secure - No insecure open ports

Perhaps this is too much of a wish list to be sensible... what are your thoughts/goals for this feature?

[mjkl-gh]

Wow! didn't hope to get such an extensive answer. Many thanks! If you don't mind i'll open a new issue and copy paste the serial relevant parts there to keep discussion organized.

---

Hi Maarten,

With regards to restructuring, the project has possibly reached the point where it may benefit from some more structure to the source code. Though like you say, where users have modified the framework code the merge would be painful for them (as would be re-visiting my own WIPs). Awkward one.

I'm sorry if i put you in a awkward position. If you would ask me for advice and this is an actual problem, I would do the following:

• Gather all WIP and features onto a list
• Announce V2.0 with breaking changes (restructure and any other feature that would break stuff)
• Finish what you wild like to finish beforehand
• Move to v2.0 at a later time, by then people will have prepared to either stop pulling changes or know of the incoming required changes

Or just keep it as it is. You've build something great and usefull here. It is up to you to decide what to do with it.

[rjwats]

Yes, I think such a change would need to be a breaking change. At the same time there are breaking changes in the UI code which I'd like to make. So it's probably a more medium-term thing.