Today we use a rough in-memory key-value store that dies when the daemon stops running.
Tomorrow we should have the ability to save stateful data in a database or store. Ideally the less opinionated we are in how/where that data is saved the more ideal it is for handling any situation.
Implementation thoughts
I want to keep the idea of storage being agnostic and extensible. My thinking is to expose some sort of interface for storage engines to plug into. The current thought here would be using Google's protocol buffers as the interface medium. Instead of requiring a code change to the daemon itself when updating or adding a storage engine, we could somehow have an endpoint or port that is pushed data from the daemon in the form of the protobuf packet. From there, the storage engine could take the packet and do with it what it wants.
The daemon itself will still need to keep a cache of socket connections on hand but can offload the more stateful data to storage
Today we use a rough in-memory key-value store that dies when the daemon stops running.
Tomorrow we should have the ability to save stateful data in a database or store. Ideally the less opinionated we are in how/where that data is saved the more ideal it is for handling any situation.
Implementation thoughts
I want to keep the idea of storage being agnostic and extensible. My thinking is to expose some sort of interface for storage engines to plug into. The current thought here would be using Google's protocol buffers as the interface medium. Instead of requiring a code change to the daemon itself when updating or adding a storage engine, we could somehow have an endpoint or port that is pushed data from the daemon in the form of the protobuf packet. From there, the storage engine could take the packet and do with it what it wants.
The daemon itself will still need to keep a cache of socket connections on hand but can offload the more stateful data to storage
.protofiles for each type (Person, Operator, Client, Chat)