JobManager 2.0 Roadmap

WHY 2.0?

New year, new major version 💯
Some of the existing design choices make it harder to implement new features. Changing them requires major code changes which may change the behavior of the JobManager in some undefined cases. Although these won't necessarily mean API changes, it may affect apps.
I hate some of the existing APIs and I would love to break them for the general health of the project. One example is the addJob method which returns a long id. It is an id but it is not necessarily unique. To be precise, it is only unique when combined with the persistence information. 👎 It is best to get rid of it and use something like a UUID.
Synchronization hell. JobManager's thread model is unnecessarily complex. Multi-threading is already complex but there are many things JobManager could do better. If I re-wrote it today, I would probably use and event driven model between JobManager components and make everything async (as much as possible). This is probably too much of a code change but cleaning up the synchronization logic will be useful.

Timer: Travis CI creates too many false negatives because many tests rely on wall clock to assert. So when the test are run slower than usual, they may fail. This requires creating a proper Time abstraction that tests can control precisely.
Job Scheduler: JobQueue badly needs this but adding new constraints in the current architecture is quite hard. Every time a new constraint is added, it will mean invalidating JobQueue API. Making constraint API more flexible will make this project a lot easier. We may even be able to provide custom constraint logic.
Rewrite resource sharing: See "synchronization hell" above.
Introduce better observability: Today, it is really hard to watch the state of a Job. Although it is usually a bad practice, sometimes it is necessary when you want to chain jobs etc. A first step here is to introduce a real id in jobs, more JobManager&Job state callbacks and maybe we can provide utilities for chaining.
Re-write internal communication: I did quick prototype on this and looks promising. It requires giving JobManager its own thread but avoid all locking (except the message queue) so should play much better with the scheduler + a lot more easier to avoid locking etc.

-- onward!