Future plans

[arkhipenko]

Moved here from #148 (comment) by @vortigont

Hi @arkhipenko,
your repo does not have 'discussions' feature enabled, so let me create an issue instead.

I was thinking about some features for TS that would be nice to have around, call it todo or not-todo list :)
Share ideas and consider if it worth the efforts to invest time into contributions or feature requests.
so, just some of the ideas that came to my mind:

xx - so much defines in code
there is so much features available in the lib and all controlled by a bunch of processor macro's. Some of them contradicts the others, some are there just to save resources, some really change lib's behavior. It becomes tricky to tailor it for various purposes, or sometimes even not possible to choose between the two.
One possible (but not easy) way to make it more configurable and extensible could be to use more Object-Oriented design (we already have objects anyway). So design a dumb Task object prototype and create a bunch of inheritable objects from it. Instead of include macro's we can simply choose between different inherited Task objects with it's own features. i.e. it could eliminate options like LTS_POINTER, OO_CALLBACKS, TIMEOUT, SCHEDULING_OPTIONS, maybe some others. Should not be an issue for the lib size, we rely on linker's here to chop off unused parts.
The same approach could be used with Scheduler to implement PRIORITY, TIME_CRITICAL or so.
Sure there could be a lot of caveats, incompatibility, etc... but it's a way to make lot's of things easier and to adopt and extend features easily either in the lib or in user code.

xx - RTOS specifics
lib sticks to Arduino's API, but as more platforms gaining rtos core it could be really handy to use some rtos features to own benefit. What comes to my mind - native mutexes, thread-safety locks, running separate threads from loop, priority, etc.

xx - need a CI tasks
with all the flags around need an automation to cover examples builds at least. Having examples in Arduino's format is not that good here, but doable. Platformio is more flexible here.

xx - Arduino IDE legacy in a nightmare
a decade(s) have passed and Arduino IDE is still the same lacking one of the most requested feature - build time define macro's to configure LIB's features. All-in-one .h file is an ugly workaround that complicates everything. Have no idea what to do with that, but it is an anchor chain on your neck :)

[arkhipenko]

So, to comment on your suggestions, @vortigont

xx - so much defines in

The library was created for early microcontrollers, like Uno and Nano with very little RAM, so every byte counted. Not as much a problem now, but I like to have a lean code compiled exactly with the functionality you need and nothing else. Maybe a bit more difficult to maintain. The object-oriented approach would generate a long list of classes with various permutations of available functionality. Think it would be just confusing. Instead you uncomment whatever defines you need and all set. In Platformio, just add -D to the main config file as in the example

xx - RTOS specifics

I am staying deliberately away from RTOS. TS philosophy is different as this is a cooperative multitasking library. There is no need in 99% of cases to use mutexes, thread safety is only a concern if you are running TS under RTOS and the same tasks could be accessed via separate threads, for which I have _TASK_THREAD_SAFE option. In a way this is an alternative to RTOS, however, I have successfully used both approaches in the past here.

xx - need a CI tasks

Agree. I wish I had the time.

xx - Arduino IDE legacy in a nightmare

Yes, but a lot of people use it and there is a very simple workaround for PlatformIO (which is my preferred dev env now). I really do not want to drop Arduino support.