Additions

[Fishwaldo]

Is your feature request related to a problem? Please describe.
Wondering if you would be interested in the following PR's:

1. Methods to return individual Schedule's from the Scheduler by ID?
2. Return a slice of all Schedule ID's in the Scheduler
3. ExpectedRunTime to be calculated from previous runs in the Scheduler (maybe controllable via a Option?)
4. Callback function when we exceed the ExpectedRunTIme? (instead of just logging)

[sherifabdlnaby]

1. Methods to return individual Schedule's from the Scheduler by ID?
2. Return a slice of all Schedule ID's in the Scheduler

Yes. as well as adding the ability to query for the state of the scheduler. I am adding these soon.

3. ExpectedRunTime to be calculated from previous runs in the Scheduler (maybe controllable via an Option?)

That's an interesting idea, we can hold an average of the previous runs and calculated the Expected Runtime based on the Average +/- A delta.

4. Callback function when we exceed the ExpectedRunTIme? (instead of just logging)

This can be an interesting option too. However, I had plans to add context to the function signature to be instead of just a func(){}, to be func(context context.Context) error. Having context so that it gets canceled by the schedule in case the job took too much time and/or the schedule is shutting down. Having the context in your func implementation would allow you to implement the callback inside the func implementation. It will be a backward-incompatible change that is ok to add as long as we're still in the 0.x.x version.

[Fishwaldo]

1. Methods to return individual Schedule's from the Scheduler by ID?
2. Return a slice of all Schedule ID's in the Scheduler

Yes. as well as adding the ability to query for the state of the scheduler. I am adding these soon.

what sort of interface were you thinking of for returning the details? Just a slice with the Schedule returned back?

1. ExpectedRunTime to be calculated from previous runs in the Scheduler (maybe controllable via an Option?)

That's an interesting idea, we can hold an average of the previous runs and calculated the Expected Runtime based on the Average +/- A delta.

Yep. That was my Thoughts as well.

1. Callback function when we exceed the ExpectedRunTIme? (instead of just logging)

This can be an interesting option too. However, I had plans to add context to the function signature to be instead of just a func(){}, to be func(context context.Context) error. Having context so that it gets canceled by the schedule in case the job took too much time and/or the schedule is shutting down. Having the context in your func implementation would allow you to implement the callback inside the func implementation. It will be a backward-incompatible change that is ok to add as long as we're still in the 0.x.x version.

That would work for me...

I was also thinking something along the lines of "middleware" executed at each State Transition. my use cases:

1. I have some jobs that can not be executed in Parallel. Right now, I'm handling it via a shared mutex in each Job Function (but that means that the "Job" from sched's perspective is actually "running". Thinking out loud - Attaching some "tags" to the context, and have a user supplied middleware check if any job is running with the same tag - then defer the job (or put it on a "run after current job finishes" type queue)
2. Similar to 1 - Some Jobs should only be run when resources are available. Again, I'm currently handling that in the Job function, but would be better in the Schedule interface, and "queue it up" to run immediately if the resource becomes available, and the At time as expired?

I think you could probably also introduce the retry/backoff item in your "TODO" as a midleware as well, which would allow users to customize how they want to handle it?