Support for External State Storage and Reusability of FSM Instances

[heartical]

Summary

We are requesting the addition of functionality to the looplab/fsm package to support saving FSM states in external storage (e.g., key/value databases) and the ability to reuse FSM instances. This will greatly enhance the flexibility and utility of the fsm package in more complex and persistent applications.

Detailed Description

External State Storage

To enhance the usability of looplab/fsm in applications where FSMs need to be durable, it would be beneficial to have built-in support for persisting and retrieving FSM states from external storage systems. This feature would allow users to:

• Persist FSM state: Save the current state of an FSM to an external storage medium (e.g., a redis, etcd, consul etc.), ensuring that FSM progress is not lost in case of application shutdown or crashes.
• Restore FSM state: Reinitialize an FSM from a previously stored state, allowing the FSM to continue from where it left off.

FSM Reusability

Another valuable enhancement would be the ability to reuse an FSM instance for multiple sequences of state transitions. Currently, FSMs are generally designed to be used once. We propose to introduce functionality that will allow:

• Resetting an FSM: Reset an FSM back to its initial state, making it possible to reuse the same FSM instance without needing to create a new one.
• Reconfigure FSM: Modify or update the FSM configuration dynamically, providing flexibility in changing state transitions or adding new states in runtime.

Benefits

• Durability: Ensures that FSM states are persistent and can survive application restarts, making the fsm package more suitable for long-running applications.
• Flexibility: Allows FSM instances to be reused, making state machines more versatile and easier to manage, especially in applications with repeating processes.
• Scalability: External storage support enables FSM states to be stored in distributed databases, paving the way for scalable and distributed state machine applications.

Proposed Implementation

In the context of this library, it might be a poor choice to tie it to a specific system. Instead, it would be better to allow the developer to invoke and configure persistent storage for the states of state machines, assuming that the default implementation would reflect the functionality of in-memory storage.

Conclusion

The proposed enhancements will significantly broaden the applicability of the looplab/fsm package, making it more robust and flexible for a wide range of applications. We appreciate your consideration of these features and look forward to their potential integration.

Thank you for your efforts and maintaining such a useful package. We are more than willing to collaborate and contribute to the development of these features.

Best regards,
Mikhail P.
@heartical

[maxekman]

Great idea!

Do you have an idea for a clean interface that storage backends could implement?