[FEATURE] - Support saving serialized scheduler and reinstating from serialized scheduler

[JohnRoesler]

Is your feature request related to a problem? Please describe

Source: #139

As a user of gocron, I would like to be able to save a scheduler when restarting my application.

Describe the solution you'd like

Expose methods to serialize and de-serialize the scheduler

Describe alternatives you've considered

• allowing jobs to be saved and re-added, this would be a lot clunkier
• making scheduler fields exported - this would expose unnecessary details to the end user

Additional context

Example serialization: https://stackoverflow.com/questions/28020070/golang-serialize-and-deserialize-back

// Export serializes the scheduler and returns a base64 encoded string
func (s *Scheduler) Export() string {}

// Import deserializes the scheduler and returns it
func ImportScheduler(in string) *Scheduler {}

I am thinking we'll want to create another struct with export fields that is used for serializing and de-serializing the main scheduler struct which contains unexported fields (which cannot be serialized using gob).

[arjunmahishi]

I was working on this a couple of months back. Got really busy. completely lost context now. That's why I unassigned myself. Will try to take a fresh stab at it if I get time.

But feel free to pick it up

[scottadamsmith]

Trying to accomplish this in our project as well. Do you think the only fields that need to be serialized on the scheduler are jobs, location, and tagsUnique?

[JohnRoesler]

I’d also include the tags map, and the time timewrapper. Are you looking at implementing here? Another option besides creating a struct with exported fields is to implement the serialize and deserialize methods on our structure, which I think is a more ideal route. I’d be happy to discuss / hack at this with you if you’re interested!

[JohnRoesler]

Looks like you have to implement:

• https://pkg.go.dev/encoding/gob#GobDecoder
• https://pkg.go.dev/encoding/gob#GobEncoder

[scottadamsmith]

For my current situation, being able to wait for running jobs to complete was enough to get me around this requirement. Our jobs are currently at specific times and are also non-critical in the way that if one run was skipped, no big deal. I do think this would be a good feature though. If I can find some time, maybe I'll take a run at it just for the experience and to lend a hand. I'm not 100% when I'll find the time though. I realized after I created this issue that do to everything being non-exported, it would be difficult to do something like this outside of the library itself.

[JohnRoesler]

I don’t see this being implemented.